The standard structure for application deployment is using 3 environments (development, testing and production). This translates to a standard set of three branches in all application repositories:
| Branch | Environment |
|---|---|
| master | approved by biz in production ( might be called also main) |
| <<issue-id>>-<<feature-name>> | usually local development environment or sandbox |
The following operational guidelines are to be should be observed:
- All branches rebased from the master till bottom from the table above ^^^
- Make sure you have a clearly defined issue in your Issues Handling System
- When a new feature is being developed, a developer will create a new feature branch from the latest version of the master/main branch as follows:
git checkout -b <<issue-id>>-<<use-the-issue-title-with-kebab-case - Features, which add complexity, but do not provide tests with CI implementation of these tests complexities MUST NOT be added to the common branches.
- When the newly developed feature is ready for inclusion, a pull request is created by the feature developer, requesting to merge his/her feature branch to dev branch. He assigns a person to perform the review of the PR and changes the Issue state to in-review
- The feature branch is deployed from the feature branch to at least 1 common cloud environment – aka there MUST be evidence that the code deploys and that the feature works
- The pull request for the feature branch is reviewed by at least 1 another member of the team and is merged to the master branch if the reviewer approves the pull request
- The updated code base is deployed to the next environments till the production environment – IF the deployment fails or anything does not go as planned – the commit is reverted
- If the reviewer does not review the PR within 24 hours the feature request creator has the right to simply merge the PR according to the flow described bellow.
- You must fetch all branches by git fetch -p –all
- update the doc/md/changelog.md file with the short description of the release
- After the the dev and the master are the same you must release by git tag v1.2.3 and git push –tags
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 Git Source Code Management System.
Each deployment to different environments should be susceptible for manual triggering via the CICD Pipelines