There are many ways to go about implementing a CI/CD pipeline using Pulumi, and we should definitely provide more documentation, guidance and examples for how to do it. (Though we don't want to be too opinionated since each team has different needs.)

Anyways, here's a standard setup for having a separate testing, staging, and production environment using a prototypical "push-to-deploy" strategy. (e.g. merging a pull request updates the code.)

First, you would create three separate stacks. One for each environment. This would also create three separate Pulumi.<stackname>.yaml files that would be checked into your source code. For example:

infrastructure/
├── Pulumi.yaml
├── Pulumi.testing.yaml
├── Pulumi.staging.yaml
├── Pulumi.production.yaml
├── ...

Those stack-specific .yaml files will contain any environment-specific configuration values checked into your source code. (For example, different values for gcp:project, or different secrets providers and encryption keys.) So you shouldn't see any merge conflicts for configuration values differing between, say, testing and production, because they are isolated in their different Pulumi.<stack-name>.yaml files.

And then, you could update staging by just creating a PR from master -> staging. And then staging -> production. (Or some other branch strategy that makes more sense for you and your team.)

You then just need to have the right CI/CD scripts determine which stack to select and deploy based on the current branch. For example:

make build
make test

# Deploy
cd infrastructure
switch (current git branch) {
    case "testing":
        plum stack select robot-co/testing
    case "staging":
        pulumi stack select robot-co/testing
    case "production":
        pulumi stack select robot-co/production
    default:
        echo "Skipping deployment for branch not tied to a specific stack"
}
pulumi stack update

You'll want to modify your scripts to also use the right credentials as well, since you likely will have your production environment running in a different account/project than your testing one. But that's the general setup.

You can see our documentation for Continuous Delivery for a little more information. But if there is anything that isn't clear, or we could add to improve the docs please let me know.