Yet another branch workflow for Git
Continuous deployment requires code to be in a ready-to-release state on a per-story basis. This can be shaped by the number of pre-live deployment environments available, the intensity level of story/functionality/bug completion and testing availability. The following scenario is possible when there is a development, staging and live environment.
The first scenario considers story completion, and also applies to related stories that need to be released simultaenously. The first step considers two stories to be released as below:
There are only ever two branches in a permanent state of availability, master and develop. Master represents the current live deployment, and is always used to branch new stories. Once the story is ready for deployment, a Pull-Request is raised to merge to develop branch. At this point it is worth noting that the develop branch is permanently being updated to the development environment, for testing.
There maybe multiple testers in the team, and this naturally assumes that stories are constantly being pushed to develop for testing. The develop branch only ever exists on the development environment.
Once the stories are tested and ready for release, the next step is to create a release branch of master. This takes into consideraion releases to live occurring while stories are being tested, and any newly created release branch always contains the live deployment code, avoiding any existing functionality being lost through branching. There should only ever be one release brarnch in existence i.e. releases are lined up in a synchronized manner.
The ready-to-deploy stories are merged into the release branch and pushed to staging. The staging environment is used to smoke-test a release and ensure all is working fine, as well as any regression testing. This ensures that there are not any unknown dependencies on stories deployed on the development environment, as well as other potential anomalies. Once this step is completed, a release is setup and deployed.
Once the release is pushed to live, the release branch is to be merged back into master, and deleted along with the story branches. If there is a P1 bug with the release then there is a slightly different workflow, incorporating pretty much the same process.
A bug branch is taken of master and deployed straight to staging for testing.
Once the story is ready for release, a release branch is created in the same way as above
Again, as in the previous process, once the bug is released to live; merge back to master and delete relevant branches
And that's it!