No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

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?

&gt; Unfortunately, I get merge conflicts in my state file.

You do not check in your state file.  That is managed by <http://app.pulumi.com|app.pulumi.com> by default, or you can manage it in cloud storage directly.  <http://app.pulumi.com|app.pulumi.com> additionally offers robust concurrency control around modifications, so only one of you can be changing the stack at a time.

&gt; 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/>.

<@ULX8829QD> 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.