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

bitter-dentist-28132

09/05/2019, 3:52 PM
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.
c

creamy-potato-29402

09/05/2019, 4:56 PM
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.
b

bitter-dentist-28132

09/05/2019, 5:13 PM
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?
c

creamy-potato-29402

09/05/2019, 6:06 PM
@bitter-dentist-28132 yeah, that’s right. I meant this more to show how to split up stuff though.
b

bitter-dentist-28132

09/05/2019, 6:31 PM
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?
c

creamy-potato-29402

09/05/2019, 6:35 PM
I think either are totally reasonable.
stacks tend to be social constructs, like microservices… so the question is, how do teams expect to interact with this stuff?
having projects split up to be inline with their code is completely reasonable.
that does mean that any time a new env is set up, you generate a lot of churn in the app teams code bases but that might be ok for you.
b

bitter-dentist-28132

09/05/2019, 6:44 PM
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.
c

cool-egg-852

09/05/2019, 8:29 PM
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.
We have ALL of our pulumi code in one repo, but a stack per project (app)
b

bitter-dentist-28132

09/05/2019, 8:37 PM
@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?
c

cool-egg-852

09/05/2019, 8:39 PM
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.
Regarding app changes that require changes in IaC, these happen rarely, and if they do, they have to be scheduled with DevOps.
Our engineering department does not have any access to IaC. We treat DevOps like a service, so we handle all of the infrastructure changes for an application.
b

bitter-dentist-28132

09/05/2019, 10:31 PM
Interesting. Thanks for the input.