Overview
We use a flavor of git flow as a source control strategy. The branching strategy git flow employs is to have 2 primary branches: main and develop. main is always deployable. The HEAD of main will always be the latest release. develop is the current state of the application. develop is almost never going to be completely stable. main and develop are both protected branches. All active development is to be done as a branch off develop.
Pull Requests
All active development is to be done by creating a branch off develop. Naming for the branch isn’t defined, but the convention that is currently in use is to create a “folder” structure like brandon/branch-name. These branches should be relatively small and focused on the task at hand. This will speed up review time and keep develop moving.
Once development of the branch is considered complete, a pull request into develop should be created. The pull request template should be used to explain the purpose of the branch and any incomplete items. The template is an outline to communicate to reviewers that there may be some incomplete work. If there are missing unit tests, outline them in the pull request description.
Before submitting the pull request, assign two reviewers to the pull request. One should be on the project with you (lead or dev) and the other is at the developer’s discretion. The requirements before being able to merge a pull requests are:
- Project builds
- All unit tests pass unless otherwise noted in the template
- Two approvals with an exception of leadership discretion
Release Management
The details for the release process are in a separate document. The information below is the high level explanation of how we work toward making periodic releases.
We aim to release at the end of every month. A release starts with a “code freeze”. A code freeze occurs when the projects slated for a given release are complete and have passed QA and any outstanding pull requests for the release are merged. Once all of the pull requests are merged, a branch off develop is created. It must follow our standard of release/Major.Minor.Patch. For example, the release candidate branch for 2.7.0 is release/2.7.0. A github project for the release should then be created for all issues found in the release candidate. Once the release candidate branch is created, development can continue on develop. The version in the Info.plist file in develop should be updated to increment the minor version (2.7.0 -> 2.8.0).
Once the release candidate branch is created, a set of alpha builds should be released. These builds are meant for internal testing and manual validation. Any issues found in the alpha build should be filed in the release project. Alpha builds should be created at least twice a day. Fixes for issues found in a release candidate should be done as a branch off the release candidate branch. Pull requests back to the release candidate branch are created and the process for pull requests should follow with the following exception: All unit tests must pass.
When the product management team has approved the release candidate, the release candidate branch can be merged into main and develop via pull request. These pull requests only need team lead approval. Once the release candidate is merged into main, a tag of main labeled Major.Minor.Patch is created. The release candidate branch can be safely deleted once it is merged into both main and develop.
Hotfixes
In the instance where a mid-release cycle hotfix needs to be released, we will create a hotfix/Major.Minor.Patch branch off main. The patch will always be one more than the patch of the latest release number. For example, if 2.7.0 has been released into the store and a hotfix needs to be released, a branch entitled hotfix/2.7.1 will be created off main. The work for the hotfix will be branch off the hotfix branch and the same process for release management is to be followed. Once the hotfix is approved, it can be merged back into main and develop via a pull request. These pull requests only need team lead approval. Once the hotfix has been merged to main, a tag with the incremented patch number should be created.
Note: When merging back to develop, be sure to not overwrite the version number in the Info.plist as it should reflect the next milestone.
Overall Flow
