Hi y’all! I could use some thoughts on best practices for stacks and projects. My project consists of DynamoDB, Lambda, an S3 bucket, and a few other tidbits. While they are part of the same overall project, they will be versioned independently and might be worked on by different teams. Ideally I don’t want to deploy the entire project if a simple change is made to the S3 bucket (or more commonly to Lambda). The project also needs to exist in several environments (dev, staging, prod). So how should I create my project(s)?
• Do I create a project for each group of resources and stacks for the environments (like lambda/dev and s3/prod)
• Do I create a project for the overall project and name my stacks based on resource type and environment (like project acmeserverless and stacks lambda-dev and s3-prod)
• Something else that I haven’t thought of
03/06/2020, 6:54 PM
projects are just namespaces for stacks, so your first option seems to make the most sense. That's what we've been doing, and also doing 1 repo per project/stack. That gives good isolation by team for deploy permissions and secrets access.
03/06/2020, 6:59 PM
Pulumi stacks can be used in several different ways, which is the reason why the official docs don't settle on a single best practice. It depends on your needs and constraints.
We organize it like this (since the project grew into several hundred aws resources in total):
• One project per group of resources / resources managed by the same Dev-team
• One stack per project for each env
• Currently we configure stack dependencies via pulumi config, but you could easily depend allways on the same stack but named like the current env. - in our case we use config because we can mix dev and staging stacks for new features..