Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

The workflow for deploying infrastructure code, broadly defined as code written using any IaC tool, including Terraform, to deploy any infrastructure changes other than a single application. For example, deploy databases, load balancers, network configurations, and DNS Settings.

First, the overall process

Infrastructure is code, and the core is code management.

[First step]

So the first part of the process is code management. The whole process includes:

  • Version control code Using VCS
  • Local Run code (Local First)
  • Update code
  • Commit changes for Review

[Step 2]

Code changes to the infrastructure description should not be implemented immediately after completion, and of course automated testing should be done. If the test passes, the following steps can be carried out. If the test fails, you need to go back to the previous step of code management for modification.

[Step 3]

After the test passes, branch merge, run, etc. The whole process includes:

  • Merge and publish
  • Implementation of the deployment

The entire process appears to be the same as the application deployment process, but there are fundamental differences, including more complex code and less easy-to-understand tools.

Version control

Just as we are accustomed to applying code through versioning, we have some additional requirements on top of this. Include:

  • Dual-library practices (real-time and module codebase)
  • Meet Terraform’s golden rule
  • Avoid multi-branch deployment

2.1 Dual-library practice

In application code, we often separate common business logic, common tools, or Infrastructure related code into packages and manage them in a separate code repository.

At least two separate version control repositories are required to store Terraform code, including:

  • Module code base
  • Real-time code base

Module code libraries one for storing module code and one for storing real-time infrastructure code. A module repository is used to store created, reusable, version controlled module code; Another real-time infrastructure repository stores the actual infrastructure deployed in each environment (Dev, Stage, Prod, and so on).

Based on the different nature of the two libraries, the module codebase recommends the creation of an infrastructure team dedicated to creating reusable, robust production-level modules. A real-time code base allows business teams to manage and leverage these modules to get their work done.

2.2 The Golden Rule

The golden rule is to maintain the code better and avoid problems with teamwork. The general idea is that “the main code branch of the real-time repository should fully represent what is actually deployed in production on a 1:1 basis.” It includes the following rules:

  • TerraformCode that represents the infrastructure environment, don’t try to manage the environment in any other way
  • Try to avoid using workspaces to manage environments, and it is strongly recommended that different environments be defined with different files and folders, i.e., what you see is all
  • Only the master can actually influence what is deployed, meaning that all changes to the environment should be reflected in the master master branch

2.3 Avoiding Multi-branch Deployment

In fact, this point has been mentioned in the golden Rule mentioned above. In multi-team combat, it is necessary to use the main branch code for deployment. If multiple branches are deployed, it is easy to cause conflicts. After all, such risk points exist and do bring many uncertain risks to the production environment.

So in general, since there is only one real world, the Terraform code with multiple branches doesn’t make much sense. Therefore, for any shared environment such as Stage, Prod, always deploy from a single branch.