DevOps Branching Strategy and Deployments

Owned by ivan.neganov (Unlicensed)
Last updated: May 27, 2022 by oussama.zeaiter (Unlicensed)
4 min read

As Vessel Registry application is approaching its “go live” date, we need to prepare our DevOps to let us add new features and release hotfixes to our production application simultaneously. The scope of the changes is the Vessel Registry repository. Shared UX components are not impacted by these changes.

The plan is to adopt “A successful Git branching model” and apply it to our development process.

The advantages of the approach are well-described in this article, as well as are the specific Git commands. Our current branching strategy differs slightly from what is proposed by it, and is more geared towards ongoing development. The following diagram illustrates its current state as well as the desired state.

As follows from the diagram, the proposed changes are relatively insignificant:

  1. Rename existing “Testing” branch to “Release branch.

  2. Create a new Hotfix branch to address production bugs or small tactical feature additions.

  3. The rest is largely “business as usual” except that new branches add additional merging operations.

Environments

Today environments have corresponding CI/CD pipelines, which will stay the same with the proposed changes, except an additional environment would be added to support Hotfixes. Currently the ACC environment is the candidate.

Iterative cycle to deployment

In order for us to deploy to production, we need to traverse the following environments:

  1. NCD - Development

  2. NCT - Testing

  3. NCA - Acceptance

  4. PCP - Production

The previous image is a visual representation of the current flow we have adopted for our release cycle. As our mindset is slowly shifting to continuous integration and continuous deployment, I have added a couple of steps that should be integrated into the current flow and can act as a pre-requisite to get us closer to that CI/CD.

  1. This is nothing new and is a typical initial step for a developer working on a local branch to initiate the pull request into the main Develop branch after completing the assigned work.

  2. This is where the first alteration to our current process occurs. Currently the process is to wait for a PBI/Bug to fully be completed prior to merging into Test. As a matter of fact, we wait for all PBIs/Bugs to be completed prior to merging into Test. As you might imagine, this is not ideal, because you are now not receiving timely feedback to be able to respond and fix any deviations from the requirements or issues. The change here is to not wait for the PBI/Bug to be marked as done, rather continuously send incremental changes to Test, and get feedback early on. Another important point to indicate here is the “Auto Merge“. Merging from Develop to test, should be automated rather than manually going and merging the branches. This coupled with Integration and Unit Tests, should be a sufficient first step to intercept and remedy any regression that might occur.

  3. Step 3 is just an indicator that even though the changes associated with a PBI/Bug are pushed to NCT, we continue with normal flow of deployment and testing.

  4. Step is where we introduce another change to the process, where we receive feedback from the PO and UI/UX, and other invested stakeholders. We verify the changes that are submitted against WCAG compliance, design, behavior, and Acceptance criteria. If changes are accepted, they proceed to the NCA/Acceptance environment, otherwise they are rejected, and comments are left on the PBI/Bug as to what needs to be fixed/adjusted.

  5. Once QA Testing Done/Passed, we merge the Testing branch into the Acceptance branch so that we can receive feedback from the end users. Similar to what was done in step 4, however, here the concentration would be mostly concentrated around receiving feedback on the alignment of the PBI/Bug to the business requirements.

  6. If any issues are detected, they are logged into PBI/Bug and the issues are resolved, otherwise the PBI/Bug is marked as done, and would be ready for release at the Product Owners discretion.

  7. Once the PO schedules a release, we can merge the Acceptance branch into Release branch and then to master, following the steps that are indicated in the deployment section.

It is important to note that when working through a sprint, the scrum team should work sequentially through the PBIs or bugs, from highest priority to lowest. This will allow the team to respond quickly to feedback. If the team works on multiple items concurrently there is a high risk of blocking the release due to incomplete functionality or untested code.

 

Deployments

Deployments will be conducted to corresponding environments in the same way as today, with one amendment: we will leverage Deployment Slots for web apps in PROD environment. The IAS pipeline needs to be updated such that the web apps are pulling built container images into a “Master” slot instead of “Production” slot. In doing so we are introducing a manual step before pushing changes “live”, but we are adding:

  • An opportunity to do last-minute smoke testing;

  • Rollback web app changes to their current version easily on a web app-by-web app basis;

  • “Warm up” the web app when deploying to “Master” slot, so there is minimal downtime when swapping “Master” and “Production” slots.