The purpose of this document is to define CSITEA’s common minimal required policies and actions for the COMPLEX branching strategy and deployment process to be performed during the life-cycle of the applications developed within the flok programme.
The standard structure for application deployment is using the following environments :
- local development environment ( lde )
- development(dev)
- staging ( stg)
- production (prd)
- masterThis translates to a standard set of three branches in all application repositories:
| Branch | Environment |
|---|---|
| master | More political than prd, this means it is not only running in production for ONE customer, but this is the public release for any instance of the code. |
| prod | contains the currently operating code in the production environment |
| release | contains the current common code to be released into the production environment during the next release |
| staging | contains the common code running in the staging ( stg ) environment |
| stg | contains the common code to be deployed to the staging( stg ) environment |
| develop | contains the common code running in the development ( dev) environment |
| <<ticket-id>>-<<feature-name>> | contains the source code being developed by the developers in their own local development environments ( local ) as well as in some cases code in the development( dev ) environment |
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 ( developandrelease) 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 GitLab Actions UI.
Ref: https://nvie.com/posts/a-successful-git-branching-model/