Four Factors to Choose the Best IaC Branching Strategy

There are plenty of resources out there for picking a branching strategy for application development, but with more and more engineering departments leveraging infrastructure as code (IaC), the need arises for a guide to choose how to branch and deploy IaC repositories. Infrastructure often has a different lifecycle when compared to the application. The factors outlined below might require your infrastructure to be branched and released differently than your application code.

There are several key factors to consider when selecting a branching strategy for IaC repositories, including:

• How often does infrastructure change? If you have rapidly changing infrastructure requirements, your branching strategy needs to accommodate rapid development cycles and frequent deployments.  
  
  
• How long does infrastructure take to deploy to production? Long deployment can prevent future development of features and should be accounted for when choosing a branching strategy.  
  
  
• Is there a need for the infrastructure to move with application deployments? Having infrastructure that is tightly coupled with your application code should dictate how infrastructure developments are branched and deployed.  
  
  
• Is there a benefit to being able to update infrastructure independently of application code? For some, being able to independently deploy infrastructure without application changes is advantageous. Frequency of change relative to application changes comes into play here; having a bigger differential between the two means a separate branching strategy or repository for IaC might be necessary.  
  

Using the above questions as criteria, there are three common scenarios you might find yourself in when architecting your IaC branching strategy.  

Scenario one: small infrastructure footprint, uniform environments, high frequency of change, IaC stored in repository distinct from application code.   

In this scenario, we recommend a trunk-based development branching plan in which developers create feature branches for IaC, testing feature branches using continuous integration (CI), merge to and deploy. With the assumption of uniform environments, your CI/CD tool of choice can handle  deployment and promotion of infrastructure code once features are merged into the main branch. With IaC separate from the application code, this decoupled nature benefits organizations with rapid releases.  

 

Scenario two: heavyweight infrastructure footprint, multiple environments requiring different configurations. 

In this scenario, we recommend an environment-based branch. This will allow for different IaC depending on the environment. With this approach, users can merge from feature to dev, then up to higher environments. Or users can change each environment individually.  We recommend an environment-based branching approach for this scenario because typical branching strategies like trunk/gitflow are difficult to implement in this type of environment. They can be challenging to manage due to the need for changes between environments. This allows different, configurable infrastructure patterns to be maintained even though they differ between environments.  

Changes can be made safely to lower environments, such as dev or staging, vetted and then graduated to QA and production. Below shows a basic flow of a single change that would be promoted from one environment to the next — but keep in mind that this strategy also allows for features/changes directly onto specific environment branches. Also note that with this approach you will lose the ability to easily merge one environment branch into the next as the commit history will diverge significantly.  

Scenario three: relatively static infrastructure footprint, multiple environments, IaC stored in same repository as application code.  

For this scenario, we recommend a Gitflow (or whatever branching strategy the application uses) based branching strategy. While you may be thinking of splitting your IaC into its own repo with its own strategy, in this type of scenario, it pays to follow the application. 

A lack of frequent infrastructure changes means there is no need for isolated, decoupled deployments. As a result, infrastructure can be changed on demand with application changes. This approach benefits teams as it removes a barrier between infrastructure and application code which empowers the development team to take a full-stack ownership approach of the code base.  

Understanding the facets of your IaC development cycles, their relationship to application code and their relationship to the business model are imperative for choosing the correct branching strategy for your infrastructure code. Having a branching strategy that fits the needs of your IaC is essential to eliminating bottlenecks, shortening feedback loops and deploying infrastructure at scale.  

Using these four key factors, you can accurately determine the best IaC branching scenario, ensuring a strategy that will maximize your team’s code quality and release rate. Looking for additional guidance on best IaC practices? Subscribe to the Tech Blog newsletter below.