Written By: Daniel Kulvicki, Solutions Director at Calavista
In Part 1, we talked through some of the misconceptions of Continuous Deployment (CD) and how it does not create a “Wild West” release approach. This time, I want to cover three major flows or processes (using GitHub as an example) that can be implemented to enable delivery of stable, high-quality features while also allowing for code to be deployed continuously. Although most of the new code will have the new features turned off, we can still ensure minimal impact to the code in production. With this approach, releases can occur at a much faster rate as we are isolating areas to test while still allowing the code to propagate through all your different environments (Dev, Test, Prod, etc.).
1. Branching Flow
While there have been many branching approaches over the years, Calavista recommends a Trunk-Based strategy for Continuous Deployment. For Continuous Deployment, you need to minimize the time and effort of merging code
changes. This means your branching strategy cannot have multiple branches that require reconciliation as changes are merged together such as you see with development branching and release branching strategies. There is some expectation of automated testing coverage on every PR due to the fact we will rely on our automated tests to reduce overall manual testing time as noted in the PR Approval Flow section below.
As teams get bigger in size, sometimes short-lived feature branches will need to be introduced. However, they must remain short lived.
Figure 1: Trunk Based Branching
2. PR Approval Flow
The PR Approval Flow ensures only high-quality code is merged into the Trunk branch. A Pull Request (or PR) is a
mechanism for a developer to notify team members that a unit of code is complete and ready for review before being merged into the code branch. Every PR that is created for Trunk will be required to go through a PR Approval Flow (such as the one below). While the approval flow may vary based on your specific needs, the flow must include the basics:
a. All PRs should create their own isolated environment for verification by people and/or automated tests
b. Each PR is tested to ensure the feature works as designed or bug fix is resolved as designed before it is merged into Trunk
Figure 2: PR Approval Flow
3. Feature Activation Flow
Since features are usually deployed before they are activated, Product Managers will want a process by which to approve when a new feature is activated. New features have the potential to be turned off for extended periods of time before they are turned on. This can be due to Marketing Campaigns, Seasonal Patterns, etc. Below you will find the recommended Calavista Feature Activation Flow for Continuous Deployment.
Figure 3: Feature Activation Flow
In my final blog on Continuous Deployment, I will focus on Dark Releases (when features are turned off when deployed) and how to implement and maintain them for your organization.
