so i've got an app that consists of a few microservices, each in their own repo. i'm deploying to kubernetes. right now, i've got a single repo with the pulumi code that deploys the entire stack, but i'd like to have the code that defines the resources specific to each microservice live alongside its corresponding code, so that e.g. review apps would work as desired without changing the code that deploys prod. is there a best practices for this? i was thinking of having an npm package inside each microservice repo, and then just `npm link`ing it when running a review app. then the "main code" would just import the various microservice packages. but maybe there's a better way of doing this.

https://github.com/pulumi/kubernetes-the-prod-way this is not really what you want but it's close. it's also a little old.

hmm, definitely interesting. in this kind of a setup, i guess you'd duplicate the stacks for the various deployments? i.e. you'd have identity-prod, infra-prod, app-1-prod, app-2-prod, identity-staging, infra-staging, app-1-staging, app-2-staging, etc?

@bitter-dentist-28132 yeah, that’s right. I meant this more to show how to split up stuff though.

in that case, would it all still be in a single repo, though? Or would you split the bits(/stacks) up per-repo, and just use the same project name?

I think either are totally reasonable.

it sounds like a hassle for CI to have everything in its own stack. unless you can programmatically get the list of stacks, and infer which ones to run and in which order. which i guess you probably couldn't do anyway? since you'd need to pull in all the source repos. unless i'm misunderstanding something here.

I’ll say the way we’re planning to solve this is that we run all apps (microservices) in 3 environments (dev, staging, prod). Any app’s PR deployment will point to the corresponding environment’s master version, not another PR deployment. We’re looking into using LaunchDarkly for feature flags so we can release code as necessary but enable it when we want. Not saying it’s the best way, but it is an option.

@cool-egg-852 how do you handle app code changes that require changes in the pulumi code? and do you spin up review/preview environments on PRs?

We currently don’t have PR review environments, but plan to. It’ll probably still make changes in our infrastructure repository. We use GitOps, and prefer to keep all infrastructure in one repo.

Interesting. Thanks for the input.