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.

trunk based branching
                                           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

PR Approval Flow
                      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.

Feature Activation Flow
                            Figure 3: Feature Activation Flow

While these approval flows provide a more substantial quality mechanism for Continuous Deployment environments, not all organizations are ready for CD. I have seen CD used effectively to create faster feedback cycles which in turn allow for a much faster feature development rate at lower costs and better overall quality. If you have teams that are not rapidly delivering high-quality code on regular, consistent basis, ask us how we can help.

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.