This message was deleted.
# generals
sparse-intern-71089
09/05/2019, 3:52 PMThis message was deleted.
c
creamy-potato-29402
09/05/2019, 4:56 PMhttps://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 PMhmm, 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 PMin 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 PMI think either are totally reasonable.
creamy-potato-29402
09/05/2019, 6:35 PMstacks tend to be social constructs, like microservices… so the question is, how do teams expect to interact with this stuff?
creamy-potato-29402
09/05/2019, 6:36 PMhaving projects split up to be inline with their code is completely reasonable.
creamy-potato-29402
09/05/2019, 6:36 PMthat 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 PMit 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 PMI’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
09/05/2019, 8:29 PMWe 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 PMWe 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.
cool-egg-852
09/05/2019, 8:39 PMRegarding app changes that require changes in IaC, these happen rarely, and if they do, they have to be scheduled with DevOps.
cool-egg-852
09/05/2019, 8:40 PMOur 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 PMInteresting. Thanks for the input.