Source Control & Deployment Process

Feature Development

Use this workflow for all new feature development. Large features should be split into "MVP" (minimum viable product) deliverables that can fit within a single sprint. Remember that features must include appropriate documentation in order to be accepted.

1. Create a "Feature Branch" off "dev" with a name matching a top-level JIRA "Story" ticket (e.x.; "DG-1234"). (If you don't have a top-level Story ticket for your new feature; create one.)
2. Commit your working code into the Feature Branch. If possible, use JIRA ticket numbers in commit messages and add descriptive comments in that ticket.
3. Once a Feature Branch is stable and ready for inclusion in a release, pull latest and merge "dev" into your Feature Branch. Resolve any conflicts that may arise in your Feature Branch. Be sure you run any automated tests that exist to ensure everything continues to work.
4. Submit a new Pull Request (PR) for your Feature Branch back into "dev".
5. Notify an appropriate resource that there is a new PR and ask them to review it. If you don't know who an appropriate resource would be, post in a general chat channel with a link to the PR. It will take at least one other developer approving a PR before it will be able to be accepted.
6. When merging a PR, please be sure to "Squash and Merge" (or, via CL, use the --no-ff option). Please note that this is not the default option in the Github UI.
7. Delete the Feature Branch.

Bug Patch

Use this workflow when patching a bug found in a deployed version. For bugs found in new features, apply the patch to the appropriate Feature Branch, using the ticket number in the commit message.

1. Create a "Patch Branch" off "master" with a name equal to a single JIRA "Bug" ticket.
2. Commit code into the Patch Branch.
3. Once the bug is successfully patched, create a new Pull Request (PR) to merge the Patch Branch into "master".
4. Also create a PR to merge the branch into "dev".
5. Notify an appropriate resource that there is a new set of PRs and ask them to review them. If you don't know who an appropriate resource would be, post in a general chat channel with a link to the PRs. It will take at least one other developer approving a PR before it will be able to be accepted.
6. When merging a PR, please be sure to "Squash and Merge" (or, via CL, use the --no-ff option). Please note that this is not the default option in the Github UI.
7. Delete the Patch Branch.

Deployment Process

Follow this workflow when code needs to be released to Production.

1. Create a "Release Branch" off of "dev" with a name equal to "release-" and the version number being released (version numbers follow the .. pattern. E.x.; "3.2.1" would be the first patch release on version 3.2).
2. Perform the required QA (automated and manual) on the Release Branch.
3. Commit any fixes on the release to the Release Branch, using the Bug ticket number as the commit message.
4. Once stable, "Squash and Merge" the Release Branch into "master".
5. Delete the Release Branch.
6. Tag the "master" branch with the release number.
7. Deploy the tag to the appropriate environment(s).
8. Merge "master" into "dev" and resolve any conflicts (working with dev team as required).