Hi Team, Apologies if this is a stupid question, ...
# getting-started
b
Hi Team, Apologies if this is a stupid question, but I've been googling around and not getting much that looks like what I'm looking for. When you are running a relatively simple setup where you have dev and prod stacks running in a single project, if there a pattern for when you want to have some resources in one stack but not the other? In my example, I want to have perhaps another/some more short-lived stack/s that I bring up on branch/es where I may not want to have the same dns/certificates that exist in the long-lived dev and prod stacks, and/or I may want to spike out some larger changes such as an alternate infrastructure setup for compute (what does it look like when I replace EKS as ECS in a somewhat contrived example). Given I have a fully featured language at my disposal, I could easily write some branching logic based on stack name or something, but I feel like when I'm dealing with IaC I still want to make what I'm writing pretty declarative and not use too much logic where people can write bugs, but maybe this is just because I've written too much yaml. Is this the recommended pattern? Put some resources behind if stack.name like ... ? Or is there a better way?
l
I would say there is nuance here, but based on what you've said a conditional part of your stack sounds acceptable to me. But to list out some more concrete thoughts: • Conditional code, as you say -- if you do this, you could still make it a bit neater by checking custom configuration rather than (say) the stack name. So e.g. in
Pulumi.dev.yaml
you pass
useECS: true
and check
if (config.useECS) { ... }
in your code, rather than
if (stack === "dev")
etc. Essentially feature-flagging your stack. • If you have quite a lot of conditions, you might just deploy another stack to the same (e.g.) AWS account that you can clean up later. Stacks are fairly cheap and you can use the full power of your language to share code and configuration as you wish. • I would argue the program is still declarative -- you are still declaring how the thing "should be", it's just that the desired state is conditional on some facts that won't appear until runtime. Hope that helps!