Chris is a Solutions Engineer at Spacelift. He has a background in cloud infrastructure with extensive hands on experience working with cloud technologies and infrastructure-as-code. 

All posts by Chris Spitzenberger - Infrastructure as Code Expert

Chris Spitzenberger

Author title

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Learn more about new features, updates, and Spacelift product announcements.

Product Features and Updates | Spacelift Blog

Product

When collaborating on infrastructure-as-code in a team environment, users typically follow a pull-request-driven workflow. This pattern is quite common throughout the software development industry, and there are various approaches in branching strategies that can be taken when working with pull requests. 
For simplification during this article, we will be assuming that users are following a <a href="https://docs.github.com/en/get-started/quickstart/github-flow" target="_blank" rel="nofollow noopener">GitHub Flow</a> branching strategy, which utilizes short-lived feature branches.

When following GitHub Flow with Spacelift, a user will create Spacelift stack(s) configured to track a specific repository and branch (and sometimes even for specific folders within a repository’s branch when working with mono-repositories). 
When ready to make changes, the user will then create a feature branch based on the stack’s tracked branch, typically “main,” which represents the source of truth. After making their feature branch, the user will complete changes in their infrastructure-as-code to add/update/remove resources in the code itself and then commit/push these changes to their feature branches on the remote repository.
The user will then wish to review the result of the plan command on the pull request itself (executed by Spacelift) after their changes have been pushed to the remote. For Terraform users, the plan result is the output of the <code>terraform plan</code> command. Similarly, for other backends (e.g., AWS CloudFormation), the plan result is the outcome of the changeset generated from the changes made.
Spacelift supports two different methods for receiving the plan result from your pull request, which we will cover in this article: Pull Request Checks and Pull Request Plan Commenting. In addition to this functionality, users can also optionally take action(s) in Spacelift based upon pull request comments or label events.
Note: With Spacelift, you can also obtain the result of the plan command locally using the <a href="https://github.com/spacelift-io/spacectl" target="_blank" rel="nofollow noopener">spacectl</a> <a href="https://docs.spacelift.io/concepts/stack/stack-settings#enable-local-preview" target="_blank" rel="noopener">local preview</a> functionality.

By default, when changes are pushed to a feature branch with an open pull request for a repository configured as a Spacelift Stack &#8211; Spacelift will create “Checks” on your pull request with the outcome of any plan(s) that were related to any proposed runs triggered on the appropriate stack(s). This behavior is highly customizable, but in general &#8211; the outcome of a “Check” looks like this, accessible from your pull request:

pull-request-checks-pr-on-spacelift

Pull Request Checks

As an optional feature, the ability to <a href="https://docs.spacelift.io/concepts/run/pull-request-comments#pull-request-plan-commenting" target="_blank" rel="noopener">comment the result of the plan directly on your pull request</a> can be enabled on a per-stack basis. This feature is optional, as commenting on pull requests can become quite noisy in terms of receiving notifications.

pull-request-plan-commenting-pr-on-spacelift

Pull Request Plan Commenting

To enable this feature, you’ll need to add the label feature:add_plan_pr_comment onto any stack you wish to enable plan commenting for. Once the label is added, on future pull requests which create proposed runs, the result of the plan will be added as a comment to your pull request. Here’s a quick video showing this functionality:
<iframe loading="lazy" title="PR Commenting Example" src="https://www.loom.com/embed/ceab2efc9dd8438588acf878c9213654" frameborder="0" width="500" height="375" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

In addition to simply being able to receive the output of the plan on your pull request, Spacelift also supports the ability to <a href="https://docs.spacelift.io/concepts/run/pull-request-comments#pull-request-comment-driven-actions" target="_blank" rel="noopener">take action in Spacelift based upon a comment</a> by a user on the pull request itself. This feature is most commonly used for achieving comment-driven deployments.
Why would I want this feature, you may ask? Well, some users prefer the ability to deploy their changes before merging, a functionality that seemingly originated from <a href="https://github.com/runatlantis/atlantis" target="_blank" rel="nofollow noopener">Atlantis</a>, an open source tool used for Terraform deployments. Whether or not to allow the ability to deploy your changes before merging is up to you at the end of the day.
As an example, a user may configure a Push policy on their stack that looks as follows:

To help us understand how this works, let’s imagine an example scenario where the policy above was attached to a hypothetical example stack we’ll call stack-a. This policy will listen for pull request “commented” events, and if a user adds the comment  “/spacelift deploy stack-a” to their pull request then a tracked run would be created for the stack, allowing users to deploy changes directly from their pull request if desired.
Note: Spacelift will only monitor for comments that begin with “/spacelift” to help prevent unintended actions within Spacelift.

<ul>
<li><a href="https://spacelift.io/blog/prometheus-exporter-for-spacelift" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Monitoring Your Spacelift Account via Prometheus&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Monitoring Your Spacelift Account via Prometheus</a></li>
<li><a href="https://spacelift.io/blog/spacelift-in-github-marketplace" target="_blank" rel="noopener">Spacelift in the GitHub Marketplace</a></li>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
</ul>

Similar to the comment-driven deployment functionality mentioned, you can also utilize pull request labels to take action within Spacelift. For example, perhaps you would like to trigger a deployment when the label “ephemeral” is added to your pull request. To achieve this result, you would attach a Push policy to your Spacelift stack similar to the following:

Users can always customize Push policies such as this one to their liking, providing a lot of flexibility.

Spacelift supports two primary ways of obtaining the outcome of your plan commands on your pull request: PR Checks and PR Plan Comments. Furthermore, you can also utilize comments or labels on your pull request to take action in Spacelift. 
Thank you for reading this article. If you found any value in this article, please feel free to share it on your favorite social media platform of choice. Wishing you the best of luck in your infrastructure-as-code efforts!
Also, if you aren’t already using Spacelift, get started on your journey by <a href="https://spacelift.io/free-trial?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bspacelift_pull_request%7D" target="_blank" rel="noopener">signing up for a Free Trial</a> and taking it for a spin around the world!

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities s for infrastructure management.

Infrastructure Drift Detection and How to Fix It With IaC Tools

Keep Your Configuration DRY with Terragrunt on Spacelift

Spacelift Worker Pools on Kubernetes with Spacelift

Learn how Spacelift supports PR Checks and PR Plan Comments. See how to utilize comments or labels on your pull request to take action in Spacelift.

94-pull-requests-on-spacelift

Working with Pull Requests on Spacelift

Pull Requests on Spacelift - PR Checks & PR Plan Commenting

As Terraform users utilize their code at scale, they typically find redundant variable declarations, complexity in deploying to multiple cloud providers, and a need to manage their growing number of dependencies across deployments. Terragrunt was built to address these use cases and others and has become quite popular amongst the Terraform community.
<h3>What is Terragrunt?</h3>
<a href="https://github.com/gruntwork-io/terragrunt" target="_blank" rel="nofollow noopener">Terragrunt</a> is an open-source wrapper for Terraform, created by Gruntwork, that provides a layer of extra features to help users manage their Terraform code at scale. The tool has become widely adopted, with over 5,800 stars and 700 forks on GitHub. Terragrunt has a laundry list of use cases for users to use. The Gruntwork team documents an official list of Terragrunt use cases <a href="https://terragrunt.gruntwork.io/docs/" target="_blank" rel="nofollow noopener">here</a>. 
In this article, we will be walking through some of the most notable use cases of Terragrunt and how they relate to the problems Terraform users face daily.

In this section, we will be discussing a select group of notable use cases (in our own words) and the benefits they provide Terraform users.
<h3>Keep Your Terraform Configuration DRY</h3>
Arguably, the most popular feature of Terragrunt is its ability to help keep your Terraform configuration D.R.Y. &#8211; Don’t Repeat Yourself &#8211; this relates to the redundancy problem mentioned earlier. Terragrunt is able to achieve this through the use of built-in functions such as find_in_parent_folders() and read_terragrunt_config(). These functions allow you to dynamically load files upstream within “parent” folders, defining them only once in a hierarchical folder structure. 
As a somewhat unintentional conflict of this DRY benefit, one could argue that fully leveraging the DRY features of Terragrunt forces users down a path of building large monorepositories. This typically occurs when users start a single repository in which they are organizing/managing all of their Terragrunt code. This isn’t always the case, of course, as it truly depends on how users choose to organize their folder structure, but it can quickly become an issue if users are not mindful of this. Although monorepositories are not necessarily always a bad thing.
The typical mono-repository Terragrunt structure follows a top-down pattern such as &lt;account&gt;/&lt;region&gt;/&lt;service&gt;/&lt;resourceName&gt;. This allows users to define variables within any top-level folder and have those variables nest down within their respective child folders. For example, one might define top-level account variables such as <code>accountId</code> or <code>accountAlias</code> within a top-level <code>account.hcl</code> file. You can define these variables only once and have them “loaded” into your lower-level folders at runtime. To do this, you will need to make use of the Terragrunt functions mentioned above. Users will find that using this feature at scale allows for cleaner code, especially when deploying many resources to consume redundant “top-level” values.
As an example, below you’ll find a code snippet of how easy it is to load in top-level variables from a file with a specific name:

<h3>Working With Multiple Providers</h3>
Using Terragrunt’s <a href="https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#generate" target="_blank" rel="nofollow noopener">generate</a> block, users are able to dynamically generate Terraform code. This feature is most commonly used for dynamically generating Terraform providers to allow for a dynamic multi-account / multi-region Terraform implementation. 
<h4>Provider Generation</h4>
Within the root-level <code>terragrunt.hcl</code> file, you will typically find the code looking something like this:

The code above will dynamically generate a <code>provider.tf</code> file containing dynamic provider contents depending upon where Terragrunt is being run. For example, if you were running <code>terragrunt apply</code> at the following path:

The <code>provider.tf</code> file would be generated within the <code>example</code> folder.
The <code>aws_region</code> variable would be loaded from the <code>region.hcl</code> file which should live within the <code>us-east-1</code> directory (assume that it exists here with that variable defined)
As a result, the contents of the <code>provider.tf</code> file would be:

Pretty cool, right? As you can see, the provider was dynamically generated at runtime simply because we defined the region within a top-level folder. Users can take this approach a step further by using account/role information within their provider blocks and can ultimately achieve the ability to assume roles in multiple accounts dynamically using this method.
 Keep in mind that technically the generate feature isn’t necessarily restricted to generating provider blocks, so you can always follow this same method to generate Terraform code for other use cases as well.

<ul>
<li><a href="https://spacelift.io/blog/terraform-environments" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Managing Multiple Terraform Environments Efficiently&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Managing Multiple Terraform Environments Efficiently</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
<li><a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:4737,&quot;3&quot;:{&quot;1&quot;:0},&quot;10&quot;:2,&quot;12&quot;:0,&quot;15&quot;:&quot;Arial&quot;}">How to Deploy your Infrastructure in CI/CD using Terraform</a></li>
</ul>

<h3>Dependency Management</h3>
With Terragrunt, two dependency-related features can easily be confused. The “dependency” block in Terragrunt allows users to define a dependency to load information from it, primarily used for loading Terraform outputs as inputs. The other dependency feature used by Terragrunt is dependencies. In the dependencies block, users specify a list of paths to folders/files, which Terragrunt should execute before executing on the current file.
Let’s walk through an example of each of these types!
<h4>The “Dependency” Block</h4>
In the code below, we specify VPC as a dependency and specify the config_path, a relative path to the dependency from which we need to load configuration. In this example, the VPC path lives back a directory in the VPC folder and produces the <code>vpc_id</code> output. Using this dependency block, we can load the vpc_id output and then use it as an input in our current configuration file (full example not shown, as we are focused on simply showing the usage of the dependency block here).
There are, of course, other ways you can pass configuration between your Terraform code, such as using AWS Parameter Store or accessing the configuration using the <code>terraform_remote_state</code> data source. Still, as you can see here, it’s rather convenient to load dependency values using this method. One limitation of this approach you’ll quickly find is that you’re understandably unable to reference dependency values deployed from other repositories. Using AWS Parameter Store or another configuration management solution is a great solution in these situations.

<h4>The “Dependencies” Block</h4>
The dependencies block is designed for enforcing the order of operations by Terragrunt. This block is meant for users who intend to eventually make use of the `run-all` functionality of Terragrunt, which allows you to execute Terraform against a group of deployments all at once or in a specified order. 
Let’s walk through a basic example of what this looks like:

Not much to see here, but notice how you can specify a list of strings, allowing you to specify n number of dependencies that you want to ensure Terragrunt executes on before executing the current file. Similar to the dependency limitation, you are constrained by relative paths, meaning you won’t be able to build dependencies for code that lives in other repositories.
Once you have your dependencies defined, you can then make the <code>run-all</code> functionality, allowing you to run plan/apply commands across your entire stack; how neat!

Terragrunt is natively supported on Spacelift and can be easily enabled by simply adding the label terragrunt on any stack(s) you would like to enable. Once this label is present, Spacelift will then utilize terragrunt plan/apply commands instead of the typical terraform plan/apply commands.

image2-22

Terragrunt: S3 Bucket

Check out this short video on how easy it is to enable Terragrunt on Spacelift:
<div style="position: relative; padding-bottom: 50.919377652050926%; height: 0;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src="https://www.loom.com/embed/4e41f88cf32c4c6b96305e94b72d68e3" frameborder="0" allowfullscreen="allowfullscreen"></iframe></div>
<h3>Why Spacelift?</h3>
Spacelift is the most flexible management platform for infrastructure-as-code. It supports not only Terraform, but AWS CloudFormation, Pulumi, and Kubernetes. Out of the box, you’ll have support for deploying to multiple cloud providers and multiple cloud accounts.
Furthermore, by running your Terragrunt commands on Spacelift, you can extend the powers of Terragrunt with the powers of Spacelift. Providing you access to other powerful features such as Spacelift <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a> and <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policies</a>. For example, using Spacelift Contexts, you can define a collection of variables and files and then attach these to Spacelift stack(s). By doing this, you then have access to those variables/files during runtime. Remember that <code>account.hcl</code> file scenario we mentioned earlier, in which you would define all of your account-specific variables? This is a great example scenario. You could create a Spacelift Context for (an account-specific context) and then attach this context to all of your Spacelift Stacks that are deploying code for that specific account. The same concept can be applied to any other grouping mechanism you’d like, whether creating a Context for a region, environment, application, etc. Contexts are a more scalable means of keeping your configuration DRY, without the side effect of creating a large monorepository.

image1-22

example account

With Spacelift Policies, we could easily have an entirely separate blog post on this topic. In summary, they allow you to build rules using the <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent (OPA)</a> to govern your infrastructure as code and its automation. For example, you may want to disallow a specific resource type or even a certain way of configuring that resource type &#8211; you can easily achieve such a thing using a <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Plan Policy</a>.

In this article, we discussed some of the common issues that Terraform users face and how Terragrunt solves them. We discussed Spacelift’s support for Terragrunt and a few of the additional features. If you found any value in this article, please share it on your social media platform of choice. Wishing you the best of luck in your infrastructure as code journey!

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation, and controls to simplify and accelerate the provisioning of cloud based infrastructures.

How Spacelift Can Improve Your Infrastructure as Code

How to Deploy your Infrastructure in CI/CD using Terraform

5 Ways to Manage Terraform at Scale - Best Practices

By running your Terragrunt commands on Spacelift, you can extend the powers of Terragrunt with other features such as Spacelift Contexts and Policies.

67-terragrunt-with-spacelift

Stay DRY with Terragrunt on Spacelift

Achieving an Atlantis Workflow on Spacelift

Running a successful <code>terraform plan</code> command pre-merge does not always mean that the <code>terraform apply</code> command will also be successful post-merge. This statement is key to understanding the value of applying changes before merging. 
For example, Amazon S3 Bucket uniqueness is validated on the AWS server-side. Due to this, users are unaware that a bucket name is not actually unique until it is created during deployment.
Users can ensure that their main branch is always reflective of error-free deployed infrastructure by applying changes before merging. If errors occur during deployment, users can correct those errors before the code changes land in the main branch.
Atlantis, in particular, has been a popular choice in the Terraform community for addressing this problem and has brought about a unique approach to applying changes from a pull request before they are merged. In this blog post, we will be discussing Atlantis and how you can implement your own Atlantis style workflow using <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>.

Once upon a time, there was Atlantis. No, we aren’t talking about the ancient mythologic civilization of Atlantis described by Plato around 360 B.C. Instead, we are talking about Atlantis, the self-hosted, open-source tool used for automating Terraform deployments.
Atlantis has become quite popular in the Terraform community, primarily due to its ease of use and purpose-built nature. Historically speaking, there haven’t been many alternatives to Atlantis in the Terraform world. In the early years of Terraform, users needed to manually build out their automation through scripts, using their own <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD</a> tool of choice &#8211; typically something like Jenkins. Unsurprisingly, some users still follow this approach and manage their CI/CD tooling automation from scratch.
Atlantis has been a game-changer in helping users accelerate their ability to obtain automation around their Terraform code. By spinning up Atlantis and configuring it to their version control system, Atlantis users can quickly get automated deployments around their code. Atlantis has some quirks, such as maintaining the Atlantis project file, but overall, Atlantis is a great tool that solves a specific problem. 
For some users, the features of Atlantis may satisfy their infrastructure automation needs, but for users with more comprehensive requirements, Atlantis may fall short.
<h3>Workflow Constraints</h3>
Out of the box, Atlantis is a tool that drives everything through pull requests (or merge requests, depending on which VCS you are using). Atlantis supports being able to customize what commands and arguments are to be run for a given Atlantis project and optionally pass in extra arguments to these commands. 
However, the overarching deployment workflow used by Atlantis cannot be changed. Users of Atlantis must open a pull request for their code if they want to invoke Atlantis in any fashion, whether their goal is to simply run a <code>terraform plan</code> or deploy their code with <code>terraform apply</code>. 
This reliance on pull requests brings about issues for users who want additional flexibility around their deployment workflows. For example, what if users wanted to trigger deployments when a new git tag is published? (rhetorical question, but this is just a single example of where this lack of flexibility begins).
<h3>Dependency Constraints</h3>
Dependency management when working with infrastructure as code is important, especially with cloud resources. Atlantis doesn’t have a native scalable means of managing your dependencies across your Terraform deployments. You can achieve this through native Terraform or Terragrunt by using things like <code>depends_on</code> and <code>dependencies</code> blocks.
 Additionally, you could structure your Atlantis project file in such a way to maintain your dependencies as well, but doing this is hacky. There have been third-party tools to help with this issue (Atlantis project file generators), but users are forced to run these tools anytime they add new files or change their dependencies. 
Later in this article, we will be describing an approach that users can utilize on Spacelift to manage their deployment dependencies.

<ul>
<li><a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Deploy your Infrastructure in CI/CD using Terraform</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Automate Terraform Deployments and Infrastructure Provisioning&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
</ul>

With Spacelift, users can build flexible workflows through Spacelift Policies. The default behavior of Spacelift will deploy changes when they land into a Spacelift Stack’s tracked branch, but for those who prefer pre-merge apply &#8211; this behavior is customizable. 
You can also configure Spacelift to deploy changes based on other conditions, perhaps a specific branch, or always allow changes to be applied pre-merge from any branch. Spacelift Policies allow you to make your deployment flow as flexible as possible. 
You can even access date/time information and require approvals during certain days of the week or times of the day, etc. The possibilities are limitless!
In addition to workflow customization, you can also use Spacelift Policies to analyze your Terraform plan results. Plan Policies allow for the ability to prevent specific resources from being deployed or enforce resources to be configured in a certain way. 
For example, perhaps you want to enforce tags are present on all resources, or specific tags always are specified on your resources. 
<h3>How to Pre-Merge Apply</h3>
When using Spacelift, if you would like your pull request changes to be applied pre-merge, you simply need to visit your pull request in the Spacelift UI and click the promote button.
Select your pull request:

image2-16

Select your pull request

Click the promote button:

image4-13

Click the promote button

By clicking the promote button, you are “promoting” your proposed run, which did not run any apply commands, into a tracked run, which does run <code>terraform apply</code> commands.

image6-6

run `terraform apply` command

It’s that easy!

With Spacelift, dependency management is easy as well. One common pattern we see used is using a Spacelift Trigger policy to trigger dependencies. You simply define a policy that, in essence, says trigger all stacks that have a label “depends-on:$this-stack” after deployment completes. 
Then, you simply attach this policy to all of your stacks, and from then on, whenever you need something to depend on something else, you can simply label it as such.
Here’s an example of a Trigger policy capable of doing this:

Let’s walk through a real-world example of using this policy.
First, we’ve created this policy and attached it to our stacks:

image3-14

Trigger dependencies

In this case, we have already attached the above policy to all of our stacks, so now we can simply define our dependencies using labels. We have built a simple dependency flow from development &gt; staging &gt; production in the example below.
You’ll notice that the staging stack contains a label that depends on the development stack, and the production stack has a label that depends on the staging stack. Having the policy attached to these stacks described previously will trigger our stacks in the appropriate environment flow order. 
Note: Depending on your use case, you may also want to apply additional policies to the staging and production stacks to prevent them from being triggered directly and only allow them to be triggered from this flow.

image1-16

Stacks

Now that we have this setup, if we were to trigger our development stack, upon completion, the staging stack is triggered, and lastly, the production stack. Users can then visualize this deployment flow in the Spacelift Runs view. Pretty neat!

image5-11

Account Runs

As you might have picked up by now, Spacelift is the most flexible management platform for infrastructure as code. <a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Similar to Atlantis</a>, Spacelift is purpose-built for infrastructure as code automation. 
Besides simply supporting Terraform deployments, Spacelift also supports other tools and languages such as AWS CloudFormation, Pulumi, and Kubernetes &#8211; with support for even more tools coming soon. But there’s more to Spacelift than simply supporting these additional tools.
<a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Spacelift Policies</a> allow users to customize their Spacelift account using policy-as-code. User-defined policies can decide things such as:
<ul>
<li style="font-weight: 400;" aria-level="1">Who gets to log in to your Spacelift account and with what level of access</li>
<li style="font-weight: 400;" aria-level="1">Who gets to access individual Stacks and with what level of access</li>
<li style="font-weight: 400;" aria-level="1">Who can approve or reject a run, and how a run can be approved</li>
<li style="font-weight: 400;" aria-level="1">Which runs and tasks can be started</li>
<li style="font-weight: 400;" aria-level="1">What infrastructure changes can be applied</li>
<li style="font-weight: 400;" aria-level="1">How Git push events are interpreted</li>
<li style="font-weight: 400;" aria-level="1">Which task commands can be executed</li>
<li style="font-weight: 400;" aria-level="1">What happens when blocking runs terminate</li>
</ul>
In addition to policies, Spacelift also offers other unique features such as Resource and Run Observability, a Module Registry, Drift Detection, and more (check <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Documentation</a>).

In this article, we described Atlantis and its pull-request-driven workflow. We then discussed how users could use the promote functionality to achieve this same pre-merge apply workflow using Spacelift. Furthermore, we talked about using Spacelift to manage your dependencies by combining a trigger policy with labels. 
Atlantis is a great tool for Terraform automation, especially for those looking to run their own completely self-hosted CI/CD solution. Currently, Spacelift does not provide a self-hosted option but instead follows a hybrid approach allowing users to run their workers on their own infrastructure while using the Spacelift UI as a service. If you’d like to see Spacelift implement a completely self-hosted option, let us know in the comments of this article!
Thank you for reading. Feel free to comment and share on your social media platform if it is of any value to you. We wish you the best of luck in your infrastructure automation journey!

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

Alternative to Atlantis – Spacelift

See Atlantis and its pull-request-driven workflow and learn how to achieve this same pre-merge apply workflow using Spacelift.

65-achieving-an-atlantis-workflow-on-spacelift

Achieving the Atlantis Workflow with Spacelift

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

How do Terraform and CloudFormation differ? In short, Terraform is an open-source Infrastructure as Code tool that has the ability to deploy resources to multiple cloud providers, while CloudFormation is an AWS service designed specifically for provisioning AWS resources.
 In this blog post, we will be comparing these two most common Infrastructure as Code options, Terraform and AWS CloudFormation, and outlining some of the key differences between them.

Terraform is an open-source Infrastructure as Code tool created by HashiCorp. Terraform utilizes a syntax called the HashiCorp Configuration Language (HCL), which allows users to define their infrastructure programmatically.
One of the most notable benefits of Terraform is that it provides the ability to deploy resources to multiple cloud providers, which makes it dare I say &#8211; “cloud agnostic.”
Although the term cloud-agnostic is often used when discussing Terraform, just because you are using Terraform doesn’t automatically make you “multi-cloud” or any more cloud agnostic than if you were using AWS CloudFormation. This is because you won’t be able to re-use the same code you’re using for one cloud provider (e.g., AWS), to deploy resources to another cloud provider (e.g., Azure). Instead, you’ll end up creating code specifically for each cloud provider. 
In addition to the “multi-provider” support that Terraform provides, there are other benefits to consider as well, such as its ability to dynamically create resources using it&#8217;s <code>for_each</code> or <code>count</code> features and the ability to dynamically configure properties of a resource with the <a href="https://spacelift.io/blog/terraform-dynamic-blocks" target="_blank" rel="noopener"><code>dynamic</code> block</a> functionality.
Additionally, Terraform supports built-in functions that can be called and used within your code, which become very useful for everyday tasks.
<h3>Providers &amp; Resource Types</h3>
Speaking of providers, Terraform itself has the concept of “<a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">providers</a>”, which you’ll need to define and configure within your code explicitly. The provider configuration is where you specify things like how you are authenticating into a particular AWS account and what region will be used for the resources you’re trying to deploy. When using a provider, each provider has its selection of  “resource types”, which are the literal items you define your code to create.
These resource types are typically cloud resources; for most folks, that’s what we are ultimately looking to define and deploy at the end of the day. When deploying resources, you’ll find that the provider name is embedded within the resource type name for a given resource, which helps users understand what provider they are currently using.
For example, if you were looking to create an Amazon S3 Bucket, you would be using the <code>aws_s3_bucket</code> resource type. Based on this naming being prefixed with <code>aws_</code>, you can tell that this resource type is within the <a href="https://spacelift.io/blog/terraform-aws-provider" target="_blank" rel="noopener"><code>aws</code> provider</a>. Pretty convenient, right?

AWS CloudFormation is an AWS service that is designed specifically for provisioning AWS resources. You have a choice of using either <a href="https://spacelift.io/blog/yaml" target="_blank" rel="noopener">YAML</a> or JSON syntax for writing your AWS CloudFormation code, both of which are natural choices for many users.
Given <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">AWS CloudFormation</a> is AWS’s native language and service for infrastructure as code, you will likely find more official quickstarts provided by AWS in the language. In addition to this, AWS Support will probably be more capable of assisting you with issues when you need help. AWS Support is essential for large enterprises, particularly those new to the cloud or slow to adopt. These types of organizations may have a skill gap within their organization regarding their cloud skill set, and in turn, they are more likely to use AWS Enterprise Support. 
Historically speaking, one of the primary reasons users would pick a tool such as Terraform over CloudFormation was the lack of support for modules. When using AWS CloudFormation, you previously needed to utilize nested templates to achieve re-usable code &#8211; and may still follow this approach today. 
Fortunately, though, in November 2020, AWS introduced support for AWS CloudFormation modules, allowing for a new way to create re-usable code. There are, of course, other significant differences between the two languages, which we will be exploring in the following section.

<ul>
<li><a href="https://spacelift.io/blog/terraform-vs-kubernetes" target="_blank" rel="noopener">Terraform vs. Kubernetes Comparison</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
</ul>

terraform_vs_cloudformation

Terraform vs CloudFormation - Comparison

<h3>1) Code Syntax</h3>
The syntax between Terraform and CloudFormation is probably the most apparent major differentiator, as many users are already familiar with writing YAML and JSON-based templates compared to <a href="https://developer.hashicorp.com/terraform/language/syntax/configuration" target="_blank" rel="nofollow noopener">Terraform’s HCL syntax</a>.
Granted, many users find HCL reasonably straightforward to learn.
<h3>2) Dynamic Features</h3>
Dynamically creating and configuring resources is a powerful feature that Terraform provides that CloudFormation currently cannot match within its standard features. AWS does offer an extension to CloudFormation called the Serverless Application Model (SAM), as well as an entirely separate tool called the AWS Cloud Development Kit (CDK), but in this case, we are focusing on standard CloudFormation features. 
The <a href="https://spacelift.io/blog/terraform-count-for-each" target="_blank" rel="noopener">terraform <code>count</code> and <code>for_each</code></a> functionality allows you to create logic to create a resource multiple times dynamically. Furthermore, you can dynamically configure your resource using the <code>dynamic</code> block feature. AWS CloudFormation, on the other hand, is much less dynamic and more explicit. With CloudFormation, you will need to define a given resource multiple times (or modularize the resource and call the given module numerous times) to create resources repeatedly.
<h3>3) Usable Functions</h3>
The ability to use built-in functions within your code can have tremendous benefits.
In Terraform, you have access to many different types of functions. A few example categories of <a href="https://spacelift.io/blog/terraform-functions-expressions-loops" target="_blank" rel="noopener">Terraform functions</a> include numeric, string manipulation, encoding, date/time, and filesystem &#8211; and this is not the complete list!
In comparison, CloudFormation is extremely limited, providing less than 15 intrinsic functions in total. The lack of helper functions can lead to annoying, complicated situations for basic tasks.
 For example, if you’re simply looking to obtain the date or time within your <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/gettingstarted.templatebasics.html" target="_blank" rel="nofollow noopener">CloudFormation template</a>, there’s no built-in function for this. Instead, you’ll need to create a custom resource within your template that calls a lambda function that returns the information you need.
<h3>4) State Management</h3>
When using Terraform, users will be quickly introduced to the concept of “state.” <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">Terraform state</a> represents stored information about your deployed infrastructure and configuration (a list of what resources have been created). 
This “state” is a file created once you run the <code>terraform apply</code> command to deploy the resources you defined in your code. You’ll need to come up with a process for maintaining your Terraform state file, whether that’s storing it in an Amazon S3, utilizing Spacelift’s <a href="https://docs.spacelift.io/vendors/terraform/state-management.html" target="_blank" rel="noopener">managed state</a> feature, or other means. The default functionality of Terraform is to keep your state locally, which is problematic when attempting to use Terraform collaboratively.
With AWS CloudFormation, this is simply something you don’t have to worry about, as CloudFormation deployments are represented within the CloudFormation service as a “stack” &#8211; showing the deployment result/events of the resources that were created/updated/deleted based on the CloudFormation template you deployed.
<h3>5) Cloud Providers</h3>
AWS CloudFormation, as the name suggests, is specific to Amazon Web Services. You can theoretically achieve deployment to third-party resources through the use of custom resources, but this is rather hacky, and at the end of the day, those third-party resources are not truly supported by CloudFormation. 
On the other hand, Terraform allows you to deploy to other cloud providers as well. Granted, you won’t be able to re-use the same codebase from one cloud provider to another. At the very least, when using Terraform, you’ll have familiar syntax and methods for deploying to different cloud providers. For some companies, this is a significant benefit, as being able to use the same syntax and deployment methods to deploy to multiple cloud providers is a clear plus.
<h3>6) Enterprise Support</h3>
If your organization uses AWS Enterprise Support, this certainly provides peace of mind knowing that AWS can assist you directly when/if you have issues with your AWS CloudFormation.
This is in comparison to Terraform, where you can also obtain support from HashiCorp directly or through the open-source community. For users that are all-in on AWS, the ability to have native knowledgeable support for your Infrastructure as Code tool is a significant benefit.

So by now, you know that you have a variety of infrastructure as code languages to choose from &#8211; with the two most common being AWS CloudFormation and Terraform, but these tools all inevitably bring about new problems that can be difficult to solve. 
Most organizations will initially go down the path of building their own custom tooling or scripts around their IaC deployments but will eventually discover that these custom-built tools often don’t scale, meet compliance requirements, and require overhead to maintain. Not to mention the fact that if you’re using multiple IaC languages, you’ll have to build multiple tools yourself or further complicate the existing custom tool you’re attempting to build.
Fortunately, there is a tool that can solve these types of problems &#8211; and provide many additional benefits, such as compliance and scalability. <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> is the most flexible CI/CD <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">tool for infrastructure as code</a> and was purpose-built for this use case. Spacelift supports multiple IaC languages (including AWS CloudFormation and Terraform), which allows you to standardize your deployment processes and compliance requirements across all of your IaC languages. Additionally, Spacelift has many unique features, such as Policies &#8211; which can be used for access controls, approvals, customizing your deployment workflows, and even creating dependencies across your IaC languages.

The battle of Terraform vs. CloudFormation is poised to be an ongoing debate. At the end of the day, this is a decision for you to make based on your preferences between the two tools. 
If having native support from AWS is essential to you, then perhaps you should consider AWS CloudFormation. If you enjoy the dynamic features that Terraform providers such as <code>count</code> and <code>for_each</code>, maybe Terraform is best.
At the end of the day, though, why restrict yourself to simply one infrastructure-as-code tool if you are able to leverage the benefits of both? There’s nothing wrong with using multiple infrastructure-as-code tools, especially if your IaC automation tool can support this.
If you want to learn how other tools compare to Terraform, see our <a href="https://spacelift.io/blog/terraform-vs-kubernetes" target="_blank" rel="noopener">Terraform vs. Kubernetes</a> article.
Thank you for taking the time to read this blog post. I wish your team the best of luck in your infrastructure-as-code journey!

Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.

Whenever you're embarking on a new journey or seeking to refine your foundational knowledge.

frame-8479-2

Frame 8479

Terraform vs. Ansible : Key Differences and Comparison of Tools

How to Build on AWS with CDK for Terraform (CDKTF)

Terraform and CloudFormation are both tools for Infrastructure as Code (IaC). We are comparing the two of them and outlining some of the key differences.

Chris Spitzenberger

Working with Pull Requests on Spacelift

Get the newsletter

Recent posts

Keep Your Configuration DRY with Terragrunt on Spacelift

Achieving the Atlantis Pull Request Automation with Spacelift

Terraform vs. AWS CloudFormation : The Ultimate Comparison