Git workflow and deployment
How we deploy product modules
Overview
Building a product module on Root often requires multiple builders working on the same code base. Therefore Git is a very useful tool to pair with product module development. We already have a guide explaining a team collaboration workflow using Git, but here we want to focus specifically on best practises for deployment. Only a Root team member can deploy a new major version of a product module.
This guide will recommending a strategy for collaboration but firstly a few principles we follow on Git when working with product modules.
- The
main
branch and the latest major version of the product module should always be in sync. - Branches should be feature specific and follow this naming convention:
<author-name>/<description>
$ git checkout -b peter/feature-quote-validation
- Pull requests should be well reviewed and tested before merging into
main
. Anything merged intomain
should be deployed immediately, as per principle1
.
Gitflow workflow
There are numerous strategies to successfully develop with Git, but we've found that the Gitflow workflow works especially well with product module development. A full guide can be found here but for brevity a short summary can be seen below.
The overall flow of Gitflow is:
- A
develop
branch is created frommain
- A
release
branch is created fromdevelop
- The
feature
branches are created fromdevelop
- When a
feature
is complete it is merged into thedevelop
branch - When the
release
branch is done it is merged intodevelop
andmain
- If an issue in
main
is detected ahotfix
branch is created frommain
- Once the
hotfix
is complete it is merged to bothdevelop
andmain

A visual representation for the Gitflow workflow from the aforementioned guide
Deployment on Root
The development environment guide explained how versioning works on the Root platform. A development cycle will happen usually in multiple draft (minor) versions of a product. Once the release
branch has been tested and reviewed, we merge it into main
. Thereafter, we should push to the product module from the main
branch, and a Root member will be requested to deploy a new major version of the product.
Keep in mind at this point all testing should have been done and the Root member will simply publish the product to a new major version. As a reminder, when a new major version is published only policies issued after that point will point to that version. All historically issued policies will still be pointing to the previous major version. Internally, we have a process called bumping that instructs all those historical policies to also point to this new major version. This is usually done after COB on the same day the deployment happened.
Updated about 1 year ago