Branching model and conventions for version-control

We are going to use GitFlow proposed branching model, with some conventions and standards to ensure a better organized branching
experience between developers and QAs.

Key Benefits

Parallel Development (feature branch)

Branches Model

GitFlow proposes two main branches to take into consideration: master and develop.

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest
delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic
nightly builds are built from.

Also, GitFlow proposes other supporting branches to master and develop: feature branches, release branches and hotfix branches.

Feature branches:
branch off from develop
are used to develop new features that are going to be merged back into develop
Release branches:
branch off from develop when develop reaches a desired state for the new release, and they should have a release number to
identify the latest release branch (version number should be defined at the moment of creation)
are used to prepare a new production release
they allow minor bug fixes
should be merged back to both develop and master. To master since each commit to master is considered a new release. To d
evelop to ensure that every change made on the release branch (bug fixes) will be tracked down to every development feature
in the future
Hotfix branches:
are like release branches but their purpose is to act immediately because a high priority bug was found in production
depending on the severity of the bug and the current state of master, the hotfix branch can be created from the tag that is
currently in production or from master
should be merged back to master and to develop. But, if the release branch currently exists (not deployed to production yet),
then the hotfix should be merged into the release branch instead of develop

The whole process can be described using the following image:

New development (new features, non-emergency bug fixes) are built in feature branches, branched off of the develop branch, and
when finished they are merged back into the develop branch:
When it is time to make a release, a release branch is created off of develop. The code in the release branch is deployed onto a
suitable test environment, tested, and any problems are fixed directly in the release branch:
When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in
the release branch aren’t accidentally lost by new development. The master branch tracks released code only. The only commits to ma
ster are merges from release branches and hotfix branches:
Hotfix branches are used to create emergency fixes. They are branched directly from a tagged release in the master branch, and
when finished are merged back into both master and develop to make sure that the hotfix isn’t accidentally lost when the next regular
release occurs:
Conventions and best practices

Here are some conventions to follow in order to have a clean versioning control process and to ensure that any developer can be able to
understand the work from other developers without problems. Conventions are listed in a Gitflow order, so we reinforce the concept

Working on a feature:

Every new branch to be created must be related to a Jira issue, and then its name should follow the convention listed below:

For Features: feature/[SPACE_ID]-[JIRA_ISSUE_NR]_{words-that-give-context}

Example: feature/DP-74_example-feature-branch
 For Hot Fixes: hotfix/[SPACE_ID]-[JIRA_ISSUE_NR]_{words-that-give-context}

Example: hotfix/DP-74_example-hotfix-branch

Once the branch is ready from development side (to understand the definition of ready, please check the Development Cycle) the
developer will be ready to create a Pull Request. When creating the PR, apart from a descriptive title, we need to give all the information
needed for both Code Reviewers and QA. There will be a template in Github that will automatically be prefilled with some fields to
complete and a checklist to ensure a well documented PR.
When the PR is raised, there are 2 things that run in parallel and need to pass before we can continue with the process:
Integrations tests run by Jenkins
Code review: there should be at least 2 approvals before we can proceed with the merge

Merging and creating release branches:

Once the PR passes the QA, the PR will be ready to merge. Since the developer is responsible for the code until it is deployed to
production, he also will be responsible for the merging into develop
The merge should create a commit on the destination branch (develop). This is commonly known as the merge-commit strategy
With the PR merged back to develop, we now can continue with the process, having a release branch created from develop when we
determine that it covers all the things needed for potential deployment to production, and have passed all the smoke tests
If some bugs are found on the release branch, they must be addressed on that branch having PRs for each bug, and merging them
back. Obviously, every time that we solve a bug in a release branch, we should also update develop branch to make it stable. To do so,
we should frequently merge changes from current release branches to develop

Merging to master and deploying:

This step should only be addressed by DevOps and/or architects to have control in the deployment process
Every time we are ready to merge a release branch to master, we need to create a tag, so we identify the deploy candidate
Bugs found in master branch should be addressed as hotfixes, making a branch from master and a PR to reintegrate those changes to b
oth master and develop