-
Notifications
You must be signed in to change notification settings - Fork 5
dynamic gateway merge process
This page is meant to document the merge process used for the dynamic gateway chart.
There will be three types of long-lived branches:
develop<release>-branchdevelop-<release>
The develop branch is the integration branch for all the latest code and bug fixes. It will always be the most cutting edge and will not be guaranteed to be stable. This branch will be the host of all CD release tags, as there will be no CD release branches.
The <release>-branch is the stable, Long Term Support release branch. <release> will correspond to a DataPower version, i.e. 2018.4.1. These branches will be the hosts of all LTS release tags.
The develop-<release> branch is the integration branch specifically for a past LTS release. Once DataPower moves on from pushing all latest code to 2018.4.1 and starts producing Continuous Delivery releases, the develop-2018.4.1 branch will be created to receive and integrate all back-ported bug fixes.
All new features and bugs will have their own branches created off of one or more of the two develop type branches. These branches are single purpose and will be named according to their purpose, i.e. logging-feature-branch or catastrophic-failure-bug-branch. Most of the time, the first place to merge a feature/bug branch will be develop. From develop, the feature/bug can be back-ported to the develop-<release> branch, if applicable. To ensure consistency, the preferred method of back-porting is to git cherry-pick the commit from develop. To maintain a clean commit history in develop, the preferred merging method is Squash and Merge.
Merging to develop and release type branches will be handled differently in PRs. For develop type branches, we want to "Squash and Merge" in PRs so that developer specific commit message formats don't clutter the commit history. This has the added benefit of making cherry-picks for specific bug fixes all the easier. For release type branches, we want "Merge commit" in PRs, so the merge history from develop type branches is maintained for tagging.
There are three merging scenarios:
- developing an LTS release
- developing a CD release
- developing a back-port fix for LTS
feature-branch ---> develop ---> <release>-branch
feature-branch ---> develop
bug-fix-branch ---> develop --(cherry-pick)--> develop-<release> ---> <release>-branch