How to scale the 'one env per branch' model?

[samlaf]

Hi everyone,

we're trying to implement a gitflow like pipeline-based strategy in our company.
I've been looking at this aws quickstart project, which I really like

This project listens for new commits in codecommit, and creates a new pipeline per branch, where each pipeline deploys a cloudformation stack to an account (master and feature branches are deployed in Development account, and when approved, the master branch is also pushed to Production account).

This works for a simple stack like in the example, which only deploys an api gateway, lambda, and dynamodb trio. However, I'm having trouble understanding how to scale this approach to a reasonably large backend. We are dealing with 100+ lambdas, api gateway routes, 10+ databases, iot routes, etc. I can't imagine having to deploy all of these just to test, say, a new feature which only impacts a single api->lambda->ddb route. However, what if the feature I am testing is a somewhat central service, which many other services need to talk to? In this case, it seems that I need to redeploy almost the entire backend just to test this new feature, in which case the one-feature-per-branch doesn't seem to make a whole lot of sense financially speaking (codebuild costs tend to add up quite fast).

So what is the most scalable environment strategy?

• one env per branch?
• one env per developer?
• only have dev, staging, prod envs?

[skinny85]

Here's my take on this. Do with it what you will 🙂.

1. Use trunk-based development. GitFlow is kind of bad. Here's my take on why.
2. You should have a bunch of shared environments - dev / staging / prod. Add or subtract as needed, but you should have at least one test environment before prod.
3. Each developer deploys their own copy of the entire microservice into AWS (ideally, into their own account, for maximum isolation) as needed as they work on them. If the microservice has other microservices as dependencies, then the local copy the developer deploys talks to its dependencies in the testing environment, to avoid the problem of having to deploy the entire system each time you need to make even a small change.

Hope this helps!

Thanks,
Adam