Hey everyone 👋 - I am trying to adopt Pulumi (I have used terraform in the past). I have a question about the right branching strategy around maintaining the pulumi code. For example, there is a use case where there are two aws environments [dev, prod] there may be more environments in the future. If I maintain only one branch for both environments and place them under one single root folder and then let say I need to add a resource in one environment but not the other; then I would have to add IF conditions to support the case. But as the number of environments grows the code would be polluted with multiple IF statements. I have thought of maintaining only one branch but making separate folders for each environment. I need someone to validate if this is the right approach.

Do you mean, SCM (git) branch? You need only one branch to deploy from. You can use branches per environment, but I don't think anyone does, and I won't recommend that. Stacks are used for describing environment. You have different configs for different environments, and the configs includes things like creds.

> If you need to add resources conditionally, you can. But you may find that a better way to arrange that is to have environment-specific projects. > For example, turning on VPC logging is a minor difference, so a condition in your code is fine. But if you need your app to be in k8s in prod, an ASG in staging and a single EC2 instance in dev.. I don't think a single project is the right way to go. Use different projects. You understand it correctly. I need to add multiple resources conditionally. As you advised to make multiple projects - I am assuming to maintain all these projects in one branch only. Is it the right assumption?

Yeah we do not maintain multiple branches for different stacks/environments. Just keep

main

as the one we always

pulumi up

from. dev feature/fix branches get

preview

but that's it. We do have one really oddball monorepo which has a

dev

and a

prod

branch and it's the only one and it is difficult to maintain as the

dev

->

prod

PRs are always big ones as feature branches are not merged through into

prod

on a 1-2-1 basis. So yeah from experience of having to look after both ways, just keep

main

for all of your stacks. It is easier / simpler 🙂

@strong-vr-23014 While I agree that maintaining one branch is easier. I am also thinking in terms of if the [

prod

,

dev

] environment have distinct resources or configuration. Lets say in

dev

I want to have AWS RDS serverless V2 database but in

prod

I need to have DynamoDB. In

dev

I want to have triggers from AWS codepipeline in

prod

I don't want to have triggers for codepipeline. To maintain this I need to have IF statements in code base. Also if in future lets say there are 10 more environments and each one of them differs from each other or at least some of them, do you think it would be cumbersome to maintain via conditional statements?

It is not cumbersome to have conditional statements. It might not be the best way to go. but it is very easy.

i've wrestled with something similar in the past. what we realized was that if there were that many differences that the

if

statements became too complicated, were they really the same project? we solved it by breaking things up into multiple projects. psuedo example • a single

network

project with

dev

and

prod

stacks (the only difference was in

dev

we added an IP whitelist to our "public" LB) • separate projects for deploying kubernetes ◦ a

k3s

project with a

dev

stack ◦ an

eks

project with a

prod

stack • a single

app

project with

dev

and

prod

stacks. the only difference was which

kubernetes

project they got their cluster information from