Branching Model
Last updated
Last updated
flxbl projects follows a with a release candidate (an equivalent of release branch ) created for each commit to the trunk. As flxbl utilizes an artifact based deployment model, branches are delinked from production.
As flxbl project operates on multiple independently deployable domains, applying a patch or hotfix has to be contextualised in the context of the domain. A temporary branch is created with commits of each individual artifact that constitutes the current state of production
A patch is applied to the temporary release branch and artifacts are generated, which are then deployed to production. A cherry pick of the commit applied on the temporary release branch is propagated into the trunk
sfp/sfops provide you with options to create a just in time release branch and all the above operations with a few commands
In , developers utilize short-lived feature branches, where an individual developer work on a very small piece of functionality. Once it is tested properly, the developer would raise a Pull Request to be integrated into the trunk ("main") branch. If the pull request validation is completed successfully and the reviewers are happy with the change, it is immediately merged into the trunk.
Each merge of a pull request into the main branch will result in creating a release candidate for the impacted domain, that is deployable to production. A release candidate is collection of artifacts and the associated version number, generated at every commit in trunk (Release candidates are defined by in ). If your team do not has need to deploy continuously to production or has single domain, you can follow the release branch model as described in the
flxbl recommends you adopt the ship/show/ask pattern for pull requests to ensure throughput in your development. You can read about ship/show/ask pattern here
