What is your approach to CI/CD with pulumi? I am working on infra monorepo 100+ projects and quite often stacks drif apart due business requirements, that something has to be deployed now or something else has to wait. • How do you handle waiting and what CI/CD services you use? • Do you use specific git branches eg dev->staging->prod or what is your strategy for deployment? • Or instead of reusing code in monorepo, do you create smaller projects dependent on a different version of your library code? Thank you for your input!

I'm not using a monorepo, so things are bit different. We have 4 environments: Dev, QA, Staging, and Production. Dev and QA are managed by Development (with Operations having read-only access) Staging and Production are managed by Operations (with Development having read-only access to Staging, and no access to Production. The pipeline looks like: Dev->QA->Package; Package->Staging->Production Dev and QA are deployed from within the repository, then a package (npm, since this is a NodeJS/TypeScript project) is produced which provides a

cloud/

directory with all the deployment code. GitHub Deployments is used to manage these deployments. The Production repository (maintained by Operations) contains an

index.ts

file which imports the

cloud/

directories from each of the packages and creates the master deployment. This is then deployed to Staging or Production based on Git tags. There's a VM running in a VPC with no internet access which pulls these tags and performs the changes. It's the only account that has permissions to change anything.

this is quite interesting, how do you communicate API changes? only via semantic versioning or is the downstream responsible for reading the changelog?

API changes to the

cloud/

for consumption within the Production repo ? Like any other software, usually if you install the upgraded package there will be type mismatches and it won't compile, but there are also release notes with the change of the dependency that describes what changed within the deployment. The interfaces are designed to not change too much, usually it's just additional configuration options for new services (e.g., now uses Twilio Sendgrid, so needs an API key and for that service to be configured a specific way -- but those configuration keys are mandatory, so it won't even compile until you provide the data)