Product

Best Practices for Infrastructure as Code (IaC) and Spacelift

447.spacelift best practices

Infrastructure as Code (IaC) is the de facto standard for managing infrastructure. It enables teams to automate and manage their infrastructure in a consistent and testable manner by ensuring that all resources are defined in code. Below, we discuss best practices for both your code and Spacelift, a tool that enhances this process.

Organize your repositories

One of the first things you should do is ensure you have well-structured repositories. Organizing your Terraform configurations and other IaC files logically within your repositories by creating consistent naming conventions for repositories, modules, and environments will help maintain clarity and ease of navigation.

At Spacelift, we see repository management ranging from IaC Monorepos to IaC Polyrepos to co-locating IaC with the application code it supports. All have pros and cons; what works for your organization depends on your goals and largely on how your team works.

Choose a Monorepo strategy if you want to keep all your IaC in one place and you don’t have strict security requirements around giving different teams access to certain parts of your codebase. You can always create login policies inside Spacelift granting access to specific Spaces to apply the code. However, cutting off access to code in a Monorepo is more challenging.

Choose a Polyrepo strategy if you do have strict security requirements around giving different teams access to certain parts of your codebase. Having a wider footprint of repositories will create new challenges, such as knowing where to go to modify certain parts of your infrastructure, but you can use things like GitHub’s RBAC to limit who has access to the individual code bases. Using standardized repository naming conventions in a Polyrepo strategy makes it easier for people to navigate to the correct repository.

Co-locating IaC with the application it supports is also a common strategy. It has the benefits of a Polyrepo strategy in that you can use your Git provider’s RBAC to control who can access the code, as well as the benefits of a Monorepo in that it should be simpler for users to find the correct code to modify. If you are co-locating your code, remember you still need to choose between a Monorepo or a Polyrepo for managing shared modules across applications.

Spacelift Spaces

Once you have figured out your repository situation, you need to consider what your Spacelift setup will look like. Every stack, context, cloud integration, and other Spacelift element resides inside a “space.” Think of this as your organizational structure for Spacelift: Who needs access to what to do some task?

1. Plan your Space structure

Design a logical structure for Spaces, based on your organizational hierarchy, projects, and environments.

At Spacelift, we typically see Spaces broken out in the same way as your organization. Still, you should also ensure that they align with your repository structure because the people in your org will be making changes to the repository, which will then be applied via Spacelift. Here is a typical setup:

spaces example

2. Use IDP groups for scalability

Utilize IDP groups to manage permissions efficiently, especially in larger teams.

Inside Spacelift login policies, you can grant access to specific Spaces using the teams attribute. Using the above example spaces layout, you can set up the following rule to allow your users to write to the R&D Team space if they are assigned the R&D team in your IDP:

 space_write[space.id] {
     space := input.spaces[_]
     space.labels[_] == "R&D Team"
     input.session.teams[_] == "R&D"
   }

This rule will allow them to run IaC in any space that inherits the R&D space team.

Note: When using Spaces, Spacelift recommends using login policies over deprecated access policies for better control over user stack/space access.

3. Regularly review and update permissions

Periodically review roles and permissions to reflect organizational changes and project requirements.

4. Leverage plan policies

Plan policies in Spacelift provide additional guardrails, enabling users to iterate independently while adhering to organizationally designated best practices.

IaC best practices

Organizations should adopt a structured approach to IaC that emphasizes consistency, security, and collaboration to optimize infrastructure management. By focusing on effective strategies and methodologies, teams can enhance their workflows and ensure reliable deployments. Below are essential best practices that can guide teams in their IaC efforts:

1. Use a reference guide

Refer to resources like Terraform best practices for specific guidelines and recommendations tailored to Terraform and OpenTofu.

Focus on code structure, style, and naming conventions. Ensure these are consistent across all your IaC, so users can easily switch between multiple code bases.

2. Modularize your code

Break down your infrastructure code into reusable modules to promote consistency and reduce duplication.

This is also your chance to enforce some guardrails. For example, have a centralized RDS module that forces users to place their instances in subnets tagged as database subnets.

3. Utilize variables and parameters

Use variables and parameters effectively to customize configurations for different environments.

Tip: Maintain self-contained variables to use variable validation at the parameter level.

If you do not use “self-contained variables,” you cannot validate the entirety of the variable implementation because variable validation cannot reference variables outside the scope of itself.

 variable "enable_vpc" {  
     type    = bool  
     default = false  
   }  
     
   variable "vpc_config" {  
     type    = object(any)  
     default = {}  
     
     validation {  
       condition     = var.enable_vpc ? "yes" : "no" # This does NOT work  
       error_message = ""  
     }  
   }

If you do use “self-contained variables,” you can validate the entirety of the implementation:

 variable "vpc" {  
     type = object({  
       enabled = bool  
       config  = any # You should define this type further in the real world  
     })  
     
     default = {  
       enabled = true  
       config  = {}  
     }  
     
     validation {  
       condition     = var.vpc.enabled && var.vpc.config ? "yes" : "no" # This does work :)  
       error_message = ""  
     }  
   }

4. Automate testing and deployment

Integrate with Spacelift’s Private Registry to automate the testing and deployment of infrastructure modules, and test changes through pull requests before merging them.

Collaboration

Collaboration is a cornerstone of effective infrastructure management. Spacelift fosters a collaborative environment where teams can ensure that changes are reviewed, tested, and validated before deployment. Here are some key aspects to enhance collaboration within your team:

1. Pull requests (PRs) showing plans:

When team members create pull requests, Spacelift automatically generates and displays a detailed plan of the proposed changes. This feature allows reviewers to see precisely what infrastructure modifications will occur, including resource additions, deletions, and updates. By visualizing these changes, team members can engage in informed discussions, ask questions, and provide feedback, ensuring everyone is aligned before any code is merged.

2. Linking directly to a plan

Instead of running Terraform locally and sharing a copy/paste of the plan output, team members can link directly to the plan generated by Spacelift. This practice streamlines the review process and ensures that everyone looks at the same version of the plan. By providing a direct link, team members can easily access the most up-to-date information, facilitating better communication and collaboration.

Additionally, Spacelift can comment the plan output directly to the pull request. This creates a deep collaboration space where reviewers can see the code change and the plan output in one place, allowing them to comment directly where they see an issue and reference specific changes in the same plan.

3. Testing module changes in the private registry

Spacelift’s Private Registry enables teams to test module changes in a secure and isolated environment. Before merging any changes, team members can validate their modifications against real-world scenarios, ensuring the infrastructure behaves as expected. This proactive testing approach minimizes the risk of introducing errors into production and creates a culture of quality assurance within the team.

Conclusion

Adopting best practices for IaC and leveraging tools like Spacelift can significantly enhance your team’s ability to manage infrastructure efficiently. By organizing your repositories, structuring your Spacelift setup thoughtfully, and fostering a culture of collaboration through effective communication and testing practices, your organization can achieve greater consistency, security, and reliability in its infrastructure deployments.

Embrace these strategies to empower your team, streamline workflows, and ultimately drive successful outcomes in your infrastructure management efforts.

If you want to learn more about Spacelift, create a free account, or book a demo with one of our engineers.

Solve your infrastructure challenges

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.

Learn more

The Practitioner’s Guide to Scaling Infrastructure as Code

Transform your IaC management to scale

securely, efficiently, and productively

into the future.

ebook global banner
Share your data and download the guide