The purpose of this document is to define an organisations common minimal required policies and actions for the COMPLEX branching strategy and deployment process to be performed during the life-cycle of the applications

The standard structure for application deployment is using the following environments :

• local development environment ( lde )

• development(dev)

• staging ( stg)

• production (prd)

• master

  This translates to a standard set of three branches in all application repositories:

The following operational guidelines are to be should be observed:

• All branches rebased from the top till bottom from the table above ^^^ – meaning for example that hotfixes in production MUST be applied to all the branches bellow in the following order – develop , stg, staging, production to every feature branch, which is WIP at the moment of the application

• When a new feature is being developed, a developer will create a new feature branch from the latest version of the develop branch. Feature branch needs to subdue to develop aka rebase

• Features, which add complexity, but do not provide tests with CI implementation of these tests complexities MUST NOT be added to any of the common branches ( check the for concrete steps to follow )

• When the newly developed feature is ready for inclusion, a pull request is created by the developer, requesting to merge his/her feature branch to develop branch.

• The pull request is reviewed by at least 1 another member of the team and is merged to develop IF the reviewer approves the pull request and all changed microservice components are tested

• The deployment to the stg environment happens from the stg branch to be made available for staging by non-technical users

• If the stg branch deployment has problems or if the non-technical users do not approve the latest deployment the staging environment, a roll-back is performed

• When the staging branch has been tested by non-technical users in the stg environment and it is considered ready for production, the deployment responsible of the feature merges the feature to the release branch (with the -X theirs and --allow-unrelated-histories flags) and tagged with a new version to enable the code state identification with the git push --tags call

• The deployment to the production environment happens from the release branch.

• IF the business representatives find a bug in the production, which could be fixed in less than 4h a hotfix branch is branched from the release branch and deployed quickly in the stg environment first, if all tests are passed quickly there too , deployed to production with a new tag. Should the hotfix take more than 4h a prio-1 bug must be created and the non-hotfix deployment followed

• After the business representatives have approved the new version in the production environment the existing prod branch is rebased with the release branch – the released git tag becomes the new “source of true” – aka what is the current version of the software operating in the production environment.

• IF the business representatives do not approve the new version, rollback to the previous production commit is carried out.

• After the release ALL common ( develop and release ) branches are rebased from the develop branch by the person performing the release. All other developers MUST also rebase their feature / bugfix branches from the develop branch – every developer must make sure that the diff between the common develop branch and the current feature / bugfix branch he/she is working on does contain ONLY changes comprising the current bug/feature he/she is working on

NOTE: Deployments to the live environments should always be done by automated CI/CD processes, never manually. In the above-described process, all moves between environments are done through the source code control system on GitLab.

Each deployment to different environments should be susceptible for manual triggering via the DevOps UI of the git based source code handling System .