For our platform… I’ve got a couple dozen microservices that’ll be deployed to 3+ different stacks (test, staging, prod -- all in different sets of GKE clusters). For each microservice, our CI pipeline looks like:

(calculate semver) 
    -> (build container, tag w/ semver, push to docker registry) 
        -> (static analysis & long-running tests) 
            -> (package helm chart w/ semver, publish to helm repo )

I was thinking I’d have a separate CD pipeline that ran the Pulumi program for deploying the service (triggered by the above CI pipeline completing). In that Pulumi program, the version of a microservice would be a part of the stack configuration. I’m assuming the Helm provider just passes the version string down to the helm cli, so I could use semver ranges to specify which version of a service belongs in each stack... something like, in the Pulumi program for svcA it’d have a config variable

svcA:version

, and it’d be set differently in each stack:

dev: >=1.1.0             # always grab the latest, even breaking changes
test: >=1.1.0,<2.0.0     # new features, but not breaking changes
staging: >=1.1.0,<1.2.0  # new bug fixes, but not new features.
production: 1.1.0        # pinned to 1.1.0

Am I setting myself up for future pain? Should I be thinking about the problem in a different way?

@powerful-elephant-53462 I’m not sure I see a problem with this, if you’re already doing this with helm this should also work with Pulumi.

that’s true… I’m no worse off. I guess I’ve got little twinges of pain every time I continue with our naive usage of k8s, where we assume for our internal microservices there’ll always be 1 version of the microservice installed into a deployment of the platform at any point in time. and haven’t done the work of getting a good blue/green CD process yet.

Makes sense.