Gitflow Workflow
We are using Gitflow Workflow. Here are step by step guides for each scenario.
Feature (or Chore)
Make sure you have current develop
git checkout develop git pull origin develop
Create a feature branch (name chore branch accordingly)
git checkout -b feature/something
Develop the feature and push the changes
git push origin feature/something
Pull request
Open pull request from feature/something to develop named Something with label
feature
(orchore
)Make sure all checks passed
Code review would be a good idea at this point
Merge pull request and remove feature branch
Release
1. Create the release candidate
Make sure you have current develop
git checkout develop git pull origin develop
Create release branch
git checkout -b release/x.y.z
Make necessary changes in the branch (update version, changelog, …)
Push the release branch
git push origin release/x.y.z
Pre-Production
Before merging to master and releasing a new version it is a good idea to deploy the release to staging
Create a tag
vx.y.z-rc.n
in the release branch, wheren
is a natural number starting from 1 (e.g.,v1.2.0-rc.1
)Once the release candidate version is built, deploy the preproduction image to staging
2. Testing on Preproduction (PPE)
Run the E2E test suite (once we will have them)
Test all features
If everything works as expected, continue with the next steps
If not, fix the problems, create a new release candidate with next number and repeat till the new version is ready
3. Release version
Pull requests
Open pull request from release/x.y.z to master named Release x.y.z with tag
release
Open pull request from release/x.y.z to develop named Release x.y.z (develop) with a label
release
Make sure all checks passed
Merge pull requests
Remove branch release/x.y.z from GitHub after both pull requests are merged
Create tag — for release, you want to usually change minor version 1.x.0, also the same minor version of client and server (and other services) should work together
git checkout master git pull origin master git tag vx.y.z git push origin vx.y.z
Get latest develop before you start working on the next feature
git checkout develop git pull origin develop
4. Update deployment example
It's needed to update FAIRDataPoint-Example
(https://github.com/FAIRDataTeam/FAIRDataPoint-Example)
Hotfix (patch version)
1. Create the release candidate
Make sure you have a current master
git checkout master git pull origin master
Create a hotfix branch
git checkout -b hotfix/x.y.z
Make fixes
Make necessary changes in the branch (update version, changelog, …)
Push the branch
git push origin hotfix/x.y.z
Pre-Production
Before merging to master and releasing a new version it is a good idea to deploy the preproduction build to staging
Create a tag
vx.y.z-rc.n
in the release branch, wheren
is a natural number starting from 1 (e.g.,v1.2.3-rc.1
)Once the release candidate version is built, deploy it to staging
2. Testing on Preproduction (PPE)
Run the E2E test suite (once we will have them)
Test all fixes
If everything works as expected, continue with the next steps
If not, fix the problems, create a new release candidate with next number and repeat till the new version is ready
3. Release version
Pull requests
Open pull request from hotfix/something to master named Hotfix x.y.z with label hotfix
Open pull request from hotfix/something to develop named Hotfix x.y.z (develop) with label
hotfix
Make sure all checks passed
Merge pull requests
Remove branch hotfix/something from GitHub after both pull requests are merged
Create tag — for the hotfix, you want to change patch version 1.0.x
git checkout master git pull origin master git tag vx.y.z git push origin vx.y.z
Get latest develop before you start working on the next feature
git checkout develop git pull origin develop
4. Update deployment example
It's needed to update FAIRDataPoint-Example
(https://github.com/FAIRDataTeam/FAIRDataPoint-Example)