Git workflow and deployment
How we deploy product modules
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.
mainbranch and the latest major version of the product module should always be in sync.
- Branches should be feature specific and follow this naming convention:
$ git checkout -b peter/feature-quote-validation
- Pull requests should be well reviewed and tested before merging into
main. Anything merged into
mainshould be deployed immediately, as per principle
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:
developbranch is created from
releasebranch is created from
featurebranches are created from
- When a
featureis complete it is merged into the
- When the
releasebranch is done it is merged into
- If an issue in
mainis detected a
hotfixbranch is created from
- Once the
hotfixis complete it is merged to both
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