bored-table-2069102/03/2022, 9:57 PM
project that provisions all the infrastructure needed (e.g. EKS, RDS, VPC and so on), and then a
project where we provision some per-tenant resources in an individual stack per tenant (and this uses a stack reference back to an
- which one to use in the stack config). So now, if I want to have dev/staging/prod type separation, I can do it in a couple of high level ways: 1. One project for
and then just name them appropriately or set some property on each stack which type of environment it lives in. 2. A project for
per environment (dev/staging/prod). Same options exist for the
project as well (i.e. one project for all envs or one per env). Code duplication is not a huge issue - 99% of the code is in some shared libraries, so the
for us is very small. The main tradeoff in my mind is that with (1), we get the simplicity of a single project, but now if we want to do something for “all staging stacks”, it becomes a much more complex operation (need to decide how to distinguish them, etc). For (2), it’s kind of reversed. I was wondering if folks have any real life experience or advice to share.
little-cartoon-1056902/03/2022, 10:07 PM
bored-table-2069102/03/2022, 10:30 PM
stacks are more like independent cells, so they share nothing with each other. I’m just thinking what I should do now to make the future easier in terms of manageability, CI/CD, permissions. Changing this stuff tends to be painful 🙂
little-cartoon-1056902/03/2022, 10:32 PM
bored-table-2069102/03/2022, 10:33 PM
infra-dev-project/ dev-stack1.yaml dev-stack2.yaml ... infra-staging-project/ ... infra-produ-project/ ...
Then if an operation I wanted to do was something like “update all staging stacks”, the logic would be quite different between the two options.
infra-project/ dev-stack1.yaml staging-stack1.yaml ...
little-cartoon-1056902/03/2022, 10:37 PM
bored-table-2069102/03/2022, 10:41 PM
branches seem like not a good fit, especially for trunk-based development. An example operation is “I want to update all the production infra stacks” - that now involves me somehow deciding from the stack what is a production one and what isn’t, as opposed to just listing all the stacks in the
project. I can of course add some custom config or use naming convention for this, but it does add complexity.
little-cartoon-1056902/03/2022, 10:51 PM
bored-table-2069102/03/2022, 10:52 PM
bored-oyster-314702/03/2022, 11:00 PM
bored-table-2069102/03/2022, 11:06 PM
bored-oyster-314702/03/2022, 11:09 PM
while your pulumi state backend could reflect
- so you could simulataneously have no code duplication in your repository and split your environments into different pulumi projects from the perspective of the state
bored-table-2069102/03/2022, 11:10 PM
and so on, to make it easier to do iterative dev work on the stack itself.