This message was deleted.

Are you planning on using Pulumi Deployments for this? Or just running the pulumi CLI within a CI system? Internally at Pulumi we have a

test

staging

and

production

stack. Each of those have separate branches. Every commit gets deployed directly to testing, and the staging/production environments are deployed on demand. We have some github automation that will create a new pull request from the main branch to the staging branch, and same for production. This isn't true continuous deployment, but we err on the side of reviewing rollouts and deploying to production only a couple of times a day due to our high availability requirements. We have other internal systems that are continuously deployed that only have one branch, and one environment but these systems are for mostly internal tools and don't have the same sort of stability/availability needs.

Hi @lemon-agent-27707, sorry for the late response, did not get notified about your reply. Our biggest concern was managing the database users as there we could have 2 types: • team member users - these are shared between environments (they are not env specific). For example that would be user accounts for developers, analysts, etc • service users - these would be used by the automated processes and they would be environment specific. For example, DEV_LOADER, PROD_LOADER, etc For that reason, I am wondering what would be the most suitable git workflow. When should the team member users be deployed throughout our CI/CD pipeline - in the dev or test or prod branch? I am open to any other suggestions on how to handle that situation. Maybe using another tool or approach? Thank you for your time!