https://pulumi.com logo
#general
Title
# general
m

mysterious-glass-86738

07/31/2019, 5:01 AM
Hey all, Something I'm struggling to understand about Pulumi at the moment is how to develop "feature branches". So, my intuition is that I'll manage my stacks locally, in a git repo. Lets say my stack file exists on the master branch. Next, I want to develop a new feature, so I create a new branch. Around the same time my coworker starts a new branch too. We both develop against the local copies of the stack file we have on our branches. My coworker merges their changes first, no problems. Next, I go to merge my changes. Unfortunately, I get merge conflicts in my state file. Is the correct way to resolve this to take their code changes and stack file, re-run Pulumi against it, and verify that I'm only making the changes I intended to make?
w

white-balloon-205

07/31/2019, 5:48 AM
Unfortunately, I get merge conflicts in my state file.
You do not check in your state file. That is managed by app.pulumi.com by default, or you can manage it in cloud storage directly. app.pulumi.com additionally offers robust concurrency control around modifications, so only one of you can be changing the stack at a time.
We both develop against the local
copies of the stack file we have on our branches The most common approach here would be to create a fresh stack from the same project with your feature branch testing, and develop in that. Then, when you open a PR against your shared branch (
master
), have either CI/CD or a manual process do an update of the shared stack associated with that branch (
production
). As a general rule, thinking of stacks as roughly 1:1 with "long lived branches" is a good starting point. There's some notes on this topic at https://www.pulumi.com/docs/reference/cd/#using-branches-for-environments that may be helpful. Also https://www.pulumi.com/docs/reference/organizing-stacks-projects/.
b

better-rainbow-14549

07/31/2019, 10:15 AM
@mysterious-glass-86738 we maintain our state in git (separate repo to the actual code), but we have infra around it to make sure it's always at the latest revision before doing anything, and to make sure that no concurrent runs are possible for a particular stack. it's a bit of a pain though, i probably wouldn't recommend doing it unless you have to.
2 Views