the team member responsible for managing the release branch and communicating with QA and management about the status of the current release
a stable snapshot of MapD Core and Immerse that contains all the desired features to be "released"
a snapshot of MapD Core and Immerse that is meant to be "released"
- Create a release branch from develop
- Check for release stability and then release
- Merge release branch into master/develop
Once the develop branch contains all the necessary features and fixes, we branch off and create a new "release" branch. This branch can be named anything.
To create a release candidate, we "upload" this branch to the Jenkins job called mapd-immerse-release. After it builds and all checks pass, we are ready to put the release candidate on the pre-production minos server (this is something Michael or Andrew will do).
After the release candidate has been uploaded to minos the release captain and QA will verify the stability of the application. Usually this takes the form of going over the "release checks" manually and/or using automated scripts to do the work.
During this check process, new bugs might be found with the release candidate. When this happens, the release captain works with QA to triage the issue, either designating it as a regular bug or as a "release blocker" if it is serious enough. Fixes to release blockers are merged into the release branch.
Once all checks have been done and no problems have been found, then the release is ready to be certified and made official.
Once the release candidate has been officially certified and released we begin the process of merging back the release back back to master and from master back to develop.
To merge the release branch into master, the release captain creates a PR. Once that is merged into master, another PR is made to merge master into develop.
After all branches have been updated, we can now tag the master branch like so:
git tag $VERSION_TAG
git push origin $VERSION_TAG
Sometimes bugs will be found in the release that need to be "hotfixed" or "patched." The hotfix process largely follows the same steps as above, the key difference being the git workflow.
To make a hotfix, we branch off the master, creating a hotfix branch. This branch serves virtually the same function as a release branch. Once the hotfix is certified, we cherry-pick the changes to master and develop.
- DO keep in contact and communicate with QA and the release channel. It always better to give more information and pre-emptively notify people on the status of the release.
- DO be aware of team bandwidth. Sometimes issues will need to be fixed to unblock a release. Be aware of what other team members are working on and always
- DO triage newly found issues. The
release blockertab carries a lot of weight, so make sure that the issue is critical enough to warrant the label