- Frequent releases (up to every day)
- Capability for manual and automated testing
- An easy process of releasing the code
- Task management and tracking is being done with YouTrack.
- Every task has a unique identifier that is used in the description of every COMMIT.
- A separate branch is created for every unique task ID.
- There are two branches that are permanent:
masteranddevelopment. masterbranch contains a stable and tested code. This branch’s code is always ready for a deployment to a Production.developmentbranch contains a code ready for testing.- It is not allowed to commit directly into
developmentandmasterbranches. All commits should be made into thefeature-branches.
- For every task there is a separate branch. All work related to this task (including bug fixing) is performed inside that branch.
- Naming convention for such branches:
bug - Code changes linked to a known issue.
feature - New feature.
hotfix - Quick fixes to the codebase.
junk - Experiments (will never be merged).
Should contain numeric ID of task, always use dashes to seperate words, and keep it short.
feature/3433-short-summary
hotfix/4353-dockerfile-base-image
bug/1234-login-ie
- Feature-branches branch off of
development. - For features/hotfixes/bugs testing use QA environment, all correct named branches will be automatically deployed to it.
- You can manually reset QA environment to
developmentbranch after testing. - When the work on a task is finalized, the feature-branch is merged into the
development, and the new version is then deployed to the development environment for final integrity test. - In case there is an additional work to be done on a task all the changes are done right in the same feature-branch. It is then being merged into the
development. No changes are allowed directly in the development as they will not get into the master branch. - After a task is ready and tested the
developmentis ready to be merged into themasterfor releasing to prod.
- A commit description should contain an ID of a task, which it relates to.
- The ID of a task should be preceded with the ‘#’ (without apostrophes) — that is for systems to understand the relation (the Bitbucket may create a link to the related issue).
- An example of a commit description: #84 changed something to something.
- The release will contain all the completed AND tested tasks (marked as ‘Done’). (Note: if a task is marked as ‘Resolved’ it has not been tested yet.)
- If a task has a dependency on another task (DEPENDS ON), it will not get into the release..
- All the branches eligible for the release are merged into the
master, then themasteris deployed to the Production. - A new version of the
masterbranch may need to be merged into into the feature-branches being not Done to allow fewer conflicts in the future.