Our general strategy is:

• master branch for all production code
• develop branch for all staging code
• feature-<name> branches when working on tasks. These merge back into develop branch.

We are using Terraform to help handle deployments so it’s not just a case of merging something into develop and it goes to the staging environment. We have to actively configure a few things and press a button to enable an actual deployment. (There are a few more nuances to it but I don’t want to get into those details here).

Deploying to Production from Staging

This strategy works well for us but there was one situation we were running into which was:

1. We would deploy an app in the staging environment.
2. Users would check these changes and then provide the green light for production deployment if everything checked out (not always the case and if not we would do another round of development and deploy to staging again).
3. Between the time of initial app deployment to staging and getting the green light to deploy to production usually more changes had been added to the develop branch.
4. We weren’t able to merge develop into master now as there had been additional changes on develop from what had been deployed and approved in staging.

So how to solve this?

Git Tags to the Rescue

This is where Git tags came in to help us. Git tags allow you to “tag” specific points in a repository’s history. These are very often used to mark something important such as a release. We started using them to mark “pre-releases”.

Therefore when we were happy with the state of develop and deployed this to staging we would create a tag from the develop branch to mark this as the code we would want to merge to master if approved. The tag name would be something like:

<app-name>-v<release-number>-pre-release
// haiko-v1.0-pre-release - Example

This tag allows us to get the code in exactly the state it was merged to develop and released to staging.

Branching from a Git Tag

Once everything is staging is approved and we’re good to release to production we then create a branch from the git tag. To do this locally you can run the following:

1. Fetch all the current tags from the remote repository

git fetch --tags

2. Checkout the tag you want to make the branch from:

git checkout tags/<tag_name>

3. Create a branch off this tag. Bear in mind at this point the code is in a “detached HEAD” state meaning you aren’t working from the top of any branch.

git checkout -b new-branch-name

With this branch you can now create a Pull Request into master and it will only push the changes that were deployed to staging and not include any code changes since that were merged to develop.

Conclusion

I have found working in a monorepo brings many benefits to a development team including quicker local development, catching changes early that could potentially cause production issues and easily having all the most up to date code running in your development environment. However, it comes with it’s own set of challenges too and one of these is deployments. When you have many changes going into the “main” working branch it can be tricky to make sure you only deploy what you want to deploy.

This strategy above has really helped us as a team gain finer control over what should and what shouldn’t be included in our deployments. It’s a simple approach and really shows the power of versioning systems when working in a collaborative environment.