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.

1. The main branch and the latest major version of the product module should always be in sync.
2. Branches should be feature specific and follow this naming convention: <author-name>/<description>

$ git checkout -b peter/feature-quote-validation

3. Pull requests should be well reviewed and tested before merging into main. Anything merged into main should be deployed immediately, as per principle 1.

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:

1. A develop branch is created from main
2. A release branch is created from develop
3. The feature branches are created from develop
4. When a feature is complete it is merged into the develop branch
5. When the release branch is done it is merged into develop and main
6. If an issue in main is detected a hotfix branch is created from main
7. Once the hotfix is complete it is merged to both develop and main

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.