Gitflow Workflow

We are using Gitflow Workflow. Here are step by step guides for each scenario.

Feature (or Chore)

  1. Make sure you have current develop

    git checkout develop git pull origin develop
  2. Create a feature branch (name chore branch accordingly)

    git checkout -b feature/something
  3. Develop the feature and push the changes

    git push origin feature/something
  4. Pull request

    1. Open pull request from feature/something to develop named Something with label feature (or chore)

    2. Make sure all checks passed

    3. Code review would be a good idea at this point

    4. Merge pull request and remove feature branch

Release

1. Create the release candidate

  1. Make sure you have current develop

  2. Create release branch

  3. Make necessary changes in the branch (update version, changelog, …)

  4. Push the release branch

  5. Pre-Production

    1. Before merging to master and releasing a new version it is a good idea to deploy the release to staging

    2. Create a tag vx.y.z-rc.n in the release branch, where n is a natural number starting from 1 (e.g., v1.2.0-rc.1)

    3. Once the release candidate version is built, deploy the preproduction image to staging

2. Testing on Preproduction (PPE)

  1. Run the E2E test suite (once we will have them)

  2. Test all features

  3. If everything works as expected, continue with the next steps

  4. If not, fix the problems, create a new release candidate with next number and repeat till the new version is ready

‌3. Release version

  1. ‌Pull requests

  1. Open pull request from release/x.y.z to master named Release x.y.z with tag release

  2. Open pull request from release/x.y.z to develop named Release x.y.z (develop) with a label release

  3. Make sure all checks passed

  4. Merge pull requests

  5. Remove branch release/x.y.z from GitHub after both pull requests are merged

  6. 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

  7. Get latest develop before you start working on the next feature

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

  1. Make sure you have a current master

  2. Create a hotfix branch

  3. Make fixes

  4. Make necessary changes in the branch (update version, changelog, …)

  5. Push the branch

  6. Pre-Production

    1. Before merging to master and releasing a new version it is a good idea to deploy the preproduction build to staging

    2. Create a tag vx.y.z-rc.n in the release branch, where n is a natural number starting from 1 (e.g., v1.2.3-rc.1)

    3. Once the release candidate version is built, deploy it to staging

2. Testing on Preproduction (PPE)

  1. Run the E2E test suite (once we will have them)

  2. Test all fixes

  3. If everything works as expected, continue with the next steps

  4. If not, fix the problems, create a new release candidate with next number and repeat till the new version is ready

3. Release version

  1. Pull requests

    1. Open pull request from hotfix/something to master named Hotfix x.y.z with label hotfix

    2. Open pull request from hotfix/something to develop named Hotfix x.y.z (develop) with label hotfix

    3. Make sure all checks passed

    4. Merge pull requests

    5. Remove branch hotfix/something from GitHub after both pull requests are merged

  2. Create tag — for the hotfix, you want to change patch version 1.0.x

  3. Get latest develop before you start working on the next feature

4. Update deployment example

It's needed to update FAIRDataPoint-Example (https://github.com/FAIRDataTeam/FAIRDataPoint-Example)