Automating Infrastructure Deployment: A Step-by-Step Guide

As we know, CI/CD can be set up in multiple ways, using tools like Jenkins, GitLab, and others. CI/CD pipelines are commonly used for various deployment types: application deployment, microservice deployment, and frontend deployment. However, when it comes to deploying infrastructure with Terraform, we often deploy it locally or set up GitHub Actions to deploy infrastructure from the respective environment.
In this blog, I’m going to share an easy and effective solution for deploying your CI/CD pipeline. This approach also incorporates all the best practices for a CI/CD pipeline.
Architecture

Explanation
Step 1: Push Terraform Code to GitHub
The process begins when a user pushes Terraform code to a GitHub repository. Upon this push, a GitHub Action is triggered, performing static code analysis using tfsec, a static analysis tool for Terraform security.
Step 2: Merge to the Main Branch
Once the branch is merged into the main branch, the changes are automatically detected by the AWS environment (in this case, the Development AWS account). This triggers the CI/CD pipeline to begin execution for the Development environment.
Step 3: AWS CodePipeline Execution
AWS CodePipeline retrieves the source code from GitHub, and AWS CodeBuild runs the terraform init
and terraform plan
command to determine which resources need to be deployed or updated. The pipeline requires approval before proceeding. If the code is approved, the pipeline continues; if rejected, the pipeline stops.
Once the plan is approved, AWS CodeDeploy is used to deploy the Terraform code to the Development environment using terraform apply
command.
Step 4: Deployment to Testing Environment
After the code is successfully deployed to the Development environment, the pipeline automatically triggers the Testing environment pipeline to execute the same process.
Step 5: Deploy to Production
Finally, just like the previous steps, the pipeline runs on the Testing environment. After successful execution, the pipeline proceeds to deploy the infrastructure to the Production environment.
How the Codebase Looks

We maintain the code in respective folders, so we can reuse the same module to deploy the same infrastructure. This approach helps us keep our infrastructure DRY (Don’t Repeat Yourself).
Important Notes
Code Approval Step
The code approval step is optional. Approval is generally not required for continuous delivery (CD). However, it is necessary in continuous deployment (CI/CD) before deploying changes.
Why Use the Same Code Every Time?
As a best practice, we follow the same artifact principle, meaning the same code is used across all environments but deployed to different AWS accounts.
There are instances where changes are made directly in production, but this is a security risk. For security and governance reasons, it’s always recommended that code passes through the development environment before reaching production. This ensures that no one is making direct changes to production without going through the pipeline process.
Conclusion
With this CI/CD pipeline setup, you gain the advantage of a secure, automated, and scalable infrastructure deployment process. By using tools like GitHub Actions, tfsec, and AWS CodePipeline, we are not only following industry best practices but also ensuring that our infrastructure deployments are efficient, reliable, and repeatable.
If you have any suggestions or questions, feel free to leave them in the comments below! I’d love to hear your thoughts