Terraform and your CI/CD workflows

Now that we have showed how to work with Terraform let us discuss how best implement it with CI/CD workflows that you might have. If you want to check our previous posts have a look at the links below:

Basics of Terraform – https://www.deployflow.co/basics-of-terraform/

Working with Terraform modules – https://www.deployflow.co/working-with-terraform-modules/

CI/CD

Let’s start with clarifying what CI/CD is – CI stand for Continues Integration (#continuesintergration) and CD stands for Continues Delivery (#continuesdelivery). The technical goal of CI is to establish a consistent and automated way to build, package, and test applications. With consistency in the integration process in place, teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality. Continuous delivery picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them. This allows the teams to become much more efficient and effective in delivering the code and the changes to the system and deploying them.

How does the CI/CD and Terraform can work together?

There are few ways to look at this and we would like to discuss few leading ideas in that space:

Terraform end-to-end

One of the approaches is to use the terraform to build your solution end-to-end, that means that anything within your environment is built, managed and controlled by the Terraform, this means that your pipelines will build the new version using Terraform and deploy onto the modules in the platform. As any approach this have pros and cons and depending on your organisation, they can determine the most appropriate solution

Pros:

  • Anything in your solution is controlled centrally by Terraform
  • You can always be sure that correct configuration is controlled centrally, and appropriate version is deployed
  • Ease of control, management and reporting on environment
  • Simpler Change Control mechanism

Cons:

  • Some of cloud items are not easily or fully managed by Terraform
  • Every time you deploy the environment would have to be re-deployed or re-set based on the changes, sometimes meaning down time
  • Dependency between the resources might be not correctly managed
  • A code change can cause outage on environment
  • Some manual changes on the environment might not get picked up by Terraform when applying and can cause security risks or issues

Terraform to manage Infrastructure and CI/CD tool to manage application

In this approach the idea is that you will use the Terraform to setup your infrastructure, account and fundamental modules of the solution, however you will use your CI/CD tool to manage the application deployments and version control. The tools we often see in use are Jenkins, TeamCity, CircleCI, BitBucket Pipelines, GitLab CICD, Octopus Deploy and few others. With this approach you might even look at solution where you use CloudFormation or Azure DevOps to deliver the application version onto the environment.

Pros:

  • Ability have shorter deployment windows as you do not have to re-scan entire environment for changes
  • Higher level of application version control as you can manage it at very granular level
  • Ability to fully control items that Terraform does not fully manage yet by using appropriate tools
  • You use the best tools for the right parts of delivery

Cons:

  • You must look after and manage additional tools
  • Harder to determine where the fix should be implemented
  • Demands larger collaboration between the teams to deliver projects
  • You need to store credentials in more platforms

Combination of the two above

In this approach you create multiple independent Terraform codes repositories to manage individual parts of the solution, and sometimes use the Terraform or CI/CD tool set to deliver the parts of the platform. This approach creates higher level of independence in your code however can be harder to manage as well as harder to get someone onboarded initially.

Pros:

  • You have very clear separation between the parts
  • You can decide on the way the code is delivered on case by case basis
  • You can create a unified modules for security, policies, access that are re-used by all sub-sections

Cons:

  • Harder to manage and to onboard team members
  • Multiple approaches on multiple levels can cause confusion and make it harder to fix
  • Storing credentials can become more problematic

Conclusion

Each of those approaches have its strengths and weaknesses that can make it more or less suitable to your situation however this shows you the flexibility of Terraform and its ability to operate in the all the different scenarios.

Here at Deployflow we have been delivering multiple projects and have come across all different combinations, and we are happy to help you make the right decision, so why don’t you get in touch to find out how we can help you?

Please find about our services – https://www.deployflow.co/services/

Share

Share on linkedin
Share on twitter
Share on facebook

Leave a Comment

Your email address will not be published. Required fields are marked *

TOP ON INSIGHTS

Basics of Terraform

So following from our last week post we would like to introduce you to basics in Terraform. Part of your DevOps research you will be

Read More »

The Journey

Monday the 8th of April 2019 marked a new landmark on our Journey — We have officially moved into our new office space in Reading. There is

Read More »
Scroll to Top