Git branch management vs deployable environments

Question

I am looking for a git branch management model that would be used easily and would allow for Continuous Integration/Delivery.

Imagine I have 3 environments: prod, uat and dev.

The code repository includes source code as well as infrastructure as code files (in this case serverless.yml)

I would like to use semantic versioning for the source code (git tags?) and I want to have auto deploys on releasing a new version.

The way I currently picture it is that there are only 2 locked branches in git: master and dev. Where master matches the current prod environment (every time I merge to master it is deployed to prod). Every commit pushed to dev is deployed to dev environment and every tag pushed to dev is deployed to uat.

All of this seems kind of possible, but there are some things unclear to me:

• How do I manage changes to the infrastructure that "doesn't affect the source code"? Let's say I need to increase the number of deployed instances etc.

• Ideally, I would only like uat-accepted versions to be released to production, how could I make sure that no untagged commits will make it to the prod environment?

I am looking for recommendations on how to approach this topic in general. Thanks!

Answer 1

Your question is very generic, and so generic answers are inevitable. That said, I figured I can share with you (at a high level) how we do our gitflow/devops at our company. You can go ahead and take a look, and then ask more specific questions.

This is our gitflow. We use AWS cloud deploy to automate the deployment of code when pushing to various git branches using bitbucket pipelines. You can see a sneak peak of how we tie that up here.