Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. follow the KFS Coding Standards (see: KFS Financials Coding Standards)

Communication

A KFS Developer is expected to:

...

  1. coordinate database changes with a KFS Product Team Engineer
  2. follow the process outlined in Changes Requiring Pre-Approval and KFS Financials Database Update Procedures for database modification requests and updates
  3. Have a local database for contribution development (see: Database)

...

  1. pull updates from the repository prior to committing code, review differences with the repository, and merge changes as necessary
  2. pull requests should be made at the story level with a single commit (squash commits)
  3. make sure commits have comments, including .  Comments should start with the JIRA # then include a short description and Jira #
  4. make sure all code compiles prior to submitting a pull request
  5. make sure the webapp runs and is in good basic working order (does a doc search work? can you create a new document? etc.) prior to submitting a pull request
  6. make sure the code you're submitting works functionally by testing it in the web application prior to submitting a pull request
  7. make sure the unit tests pass prior to submitting a pull request (See: Running Unit Tests)
    1. At a minimum, this means executing the PreCommitSuite to ensure no failures. Failures in this minimal test suite may indicate other developers will be impeded from their development
    2. If there are unit tests specific to the areas of code being changed in the commit, run those as well, and ensure they pass
    3. In general, developers don't need to run the full suite of unit tests locally before submitting a pull request, because they are run regularly by our CI serveron each pull request; an exception would be when making a wide sweeping change such as changing from Java 7 to Java 8.

Technical Documentation

A KFS Developer is expected to:

...