Should the infrastructure code be stored in the same repository as the application code?

Question

I am setting up an infrastructure to support a WebApp. One of my repositories have all the Network Infrastructure (VPC, Subnets, NAT, Bastion and so on). The WebApp has a Route 53 + ALB + AutoScalling Group + EC2 Instances. All of them were coded in Cloudformation templates. My question is if the WebApp Cloudformation templates should be store in the same repository as the application? Is there any best practice on how to separate infrastructure and app code?

Manipulator

No one answered. I am curious too. – Anisaanise

There is also a very similar question here - discuss.hashicorp.com/t/… posted just 9 days ago. So far - no answer. I have taken a liberty to add the terraform tag, because your question is not really specific to any cloud provider. My guess is that the terraform tag is going to attract more attention. – Anisaanise

I was also searching for some insight from others on this, and this is the first SO question to come up when searching "should i put infrastructure as code in the project repo". Please upvote this question if you are here under similar circumstances! – Llano

Answer 1

As a general rule you should keep your infrastructure next to the application code. So, yes you should have it in the same repository.

Of course you might be in the case in which some resources are shared between different projects. In this case I suggest you to have a separate repository containing only the shared piece of infrastructure. What I would do here would be the following:

• one repository for shared infrastructure: VPC, public and private subnets, dns root zones.
• one repository with your webapp and its relative infrastructure.

This gives you the benefit to implement pipelines that build artifacts and apply new infrastructure at the same time.

Skit

I would be concerned that, if the IaC code and source are in the same place, you have no separate of access. Your application developers can modify the infrastructure deployment pipeline and potentially cause much more damage or security issues than was possible in just the code. You'd need to be very very sure that you have separate access for prod and nonprod in your pipeline workers and that environments are cleaned up. Its definitely easier to have it all in one repo but I'm not comfortable with the security implications – Disperse

Answer 2

I will propose the following food for thought:

It seems like a natural progression would be to have IaC code included, and as the project grows you split it out when you run into barriers like:

• The deployed project now has multiple source projects/repos involved
• Protect/prevent accidental changes to IaC code depending on who has access to the repo
• A clean commit history is desirable for observing changes to infrastructure and deployments

I personally like to follow the path of least resistance when working on something -- when it's a single developer and you are rapidly prototyping a proof-of-concept there is certainly advantages having your TF files and ci-cd pipelines all in one place. Once you are sharing your code base and more rigorous standards come into place then it's time to mature your standards.

Depending on your experience and if you know the project will eventually need it, it might make sense to include many best practices from the get-go (aggregated logging, SAST/DAST, code linting and published contribution guidelines). But if you are still navigating all of these concepts for the first time, it probably makes sense to wait until it becomes a pain-point. Kind of Technical Debt vs YAGNI.

Llano

Just thinking out loud: A funny approach for a "clean commit history" would be to maintain a dedicated "iac" branch, e.g. starting from the initial commit. – Frankie

Answer 3

This is really a matter of opinion, but I think the trend is to keep everything needed for your application/service with the code. With that said, you will often have things that are shared (e.g. a VPC), you often end up having those in a separate repo (depending on how you organize your code; there seems to be a push for mono repos these days).

CloudFormation Best Practices has some good information on organizing your stacks, though it doesn't address your question.

Epirus