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

stale-answer-34162

12/08/2023, 4:22 PM
@stocky-restaurant-98004 How do you guys recommend using pulumi with a monorepo application that generates helm charts (for the moment until kustomize)?
s

stocky-restaurant-98004

12/08/2023, 4:26 PM
There's a couple of options on how to do this. You can put infra alongside app code, or you can make a trigger so that a release of the app code triggers your infra pipeline for a deployment.
If you wanna to continuous deployment, the sequence of events would be like: new app build -> helm charts output from app build -> trigger Pulumi pipeline (possibly with a manual update to your stack config that says what version of the Helm chart to deploy). Does that answer your question?
s

stale-answer-34162

12/08/2023, 4:27 PM
it does! tyvm!
I guess one more followup, how does this look for a project and stack organization tree?
Copy code
aws
   ├── eks
        └── dev
        └── staging
        └── prod    
   └── rabbitmq
        └── dev
        └── staging
        └── prod
s

stocky-restaurant-98004

12/08/2023, 5:01 PM
You don't have to organize by cloud or AWS service (unless that's intentional to limit blast radius).
Presumably you're gonna want some rabbitmq stuff in your K8s resources, e.g. a configmap, so you might benefit from putting them all together. Basically, I recommend you avoid stack refs until you really need them. Stack refs are almost the analogue of going from a monolith to a distributed architecture - don't do it until you need it. Pulumi is designed to coordinate all that stuff together.
When it comes to this design decision of multiple programs w/stack references, try to think through what changes you might see in the future and play it out: When we make this change, does it feel more "ergonomic" in a monorepo with a single Pulumi program, or multiple programs?
Conway's Law is also huge here. When I talk about stack refs, the canonical example I use is for a fictional larger org where you have a network team (VPCs and Transit Gateway), a platform team (EKS clusters deployed to the VPC subnets), and app teams (K8s resources deployed to the EKS clusters).