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

Third, local run code

For application code, we can easily build the environment natively to simulate real business scenarios for testing, but for infrastructure-related code, we can’t create compute instances, database instances, and so on natively. However, to ensure robustness and security in production, it is important to test it before deployment. With Terraform, the only way we can test it manually is to run it in a sandbox environment.

The so-called sandbox environment, for example, applies a cloud resource operation account for development, then applies the relevant operation, and finally uses Curl to verify whether the deployment is successful.

Make code changes and submit reviews

Making code changes, of course, refers to iterative changes to the code, after which validation tests need to be deployed. This section emphasizes how to save validation time during validation. Core themes can be verified selectively rather than at the whole stage. For example, they can be selectively deployed at the application level instead of creating or destroying resources. In this way, feedback time can be greatly reduced and efficiency can be improved.

Submit code and review This part of the application code development, many development teams adhere to, the core is to create a pull Request to complete code review. Team warfare requires everyone to follow the same set of coding principles and code styles, and this can be achieved through code reviews.

Automated testing

As with application code, continuous integration (CI) can be satisfied using automated tests. By intercepting the script, the automated testing process in the CI server is triggered after each commit and the results of the test are displayed in the pull Request. To do this, we need to do two things:

  • Write unit tests, integration tests, and end-to-end tests for Terraform code
  • useAtlantisOpen source tool that runs automatically when code is submittedterraform planCommand and add the output of the plan command to the comment of the pull request.

Merge and publish

After code changes and planned output have been reviewed by team members and all tests have been completed. You can merge the changes into the Master branch and publish the code. Similar to the application code flow, you can use Git tags to create released versions.

Because Terraform supports direct downloading of code from Git repositories, the repository state of a particular tag is an immutable, version-controlled artifact that will be deployed.

Seven, deployment,

Once the above code is written, versioning, validation, and automated testing is complete, deployment begins. There are some optimizations and considerations for deploying the Terraform code to make it more efficient.

7.1 Deploying Tools

Terraform itself is a tool, but it is limited in some ways, There are deployment tools including Atlantis (for pull Request), Terraform Enterprise (providing UI, administrative variables, confidentiality, and access rights), Terragunt (deployment enhancements), and even scripts that can improve the overall deployment management process.

7.2 Deployment Policies

Terraform itself does not provide any deployment strategy, requiring the development of its own modules to support zero downtime, rolling deployment, blue-green deployment, and Canary deployment. However, due to the limitations of its language itself, the control ability is very limited, so it needs to pay attention to design. Strategically retry, focus on Terraform state errors, and have a fail-safe for lock release errors.

There are other considerations, such as having a separate deployment server rather than operating on the developer machine; And the CI server should be strictly controlled and so on.