This message was deleted.

My biggest concern is upgrading a dependency without it deploying to all environments simultaneously, but also not blocking other deployments. Example: • Component foo updated from v1 to v2 • Dev starts using v2 • Qa, staging, prod stay on v1 • An unrelated change is made to qa.

Pulumi up

doesn't attempt to use foo v2 in qa and only the unrelated change is in the diff

I have a monorepo. My deployment pipeline is based around branches. CI builds (for a branch under review) are deployed to their own stack. Master is deployed to test and then (after manual approval) deployed to prod, each as separate stacks. However, the pulumi logic is largely the same, though there are some variations (based on config) for different stacks / environments.

how do you handle a scenario where environments need different types of resources? for example, in our dev, due to cost, we use azure's sql server. in staging/prod we use sql managed instances.

I use multiple projects per product, a stack in each project for each environment. Environments mean different things in different projects: for the VPC project, "environment" and "account" are synonymous. For the DB project, "environment" means prod/staging/dev, etc.: prod/staging are in one account, dev/test is in a different one. Many ways to skin a cat!

@early-sugar-1496 I use configuration. For example, in dev/staging, I only run 1 container with our API, but in prod I run 2 (for failover). I deploy different stacks for each environment, with associated config, but its all the same code.