Branching model and Code Pipeline life cycle


The Git repository uses a branching model consisting of two long lived branches and short-lived feature or hotfix branches.

  • feature/FT<n>/<branch_name> - branches of this form are used to implement user stories. The Code Pipeline branch mapping rules in use, assure that branches whose name start with feature/FT<n> will get mapped to a corresponding FT<n> level in the Code Pipeline application's life cycle.
  • bugfix/<branch_name> - branches of this form are used to implement bug fixes. The Code Pipeline branch mapping rules in use, assure that branches whose name start with bugfix will get mapped to the HFIX level in the Code Pipeline application's life cycle.
  • development - this is the first long lived branch. Any development work feature branches are branched off and merged into the development branch. The Code Pipeline branch mapping rules in use, assure that the development branch will get mapped to the DEVL level in the Code Pipeline application's life cycle.
  • main - the second long lived branch. At any time, the main branch is supposed to be in a state that is "production ready". Meaning that a merge from the development branch into the main branch will result in the code to be released to production. The Code Pipeline branch mapping rules in use, assure that the main branch will get mapped to the MAIN level in the Code Pipeline application's life cycle.


Code residing in the main branch / at the MAIN level is ready to be released to production. There is a PROD level in the Code Pipeline life cycle, which represents production, and does not have a matching Git branch. Instead Code Pipeline promote, release and deploy are used to move code from the MAIN level into production.

Likewise, there are no Git branches directly matching the lowest levels (UT<n>, BUG1) in the Code Pipelinelife cycle. Instead, these levels get synchronized from the local developer's workspace using the Git/Code Pipeline within Total Test. The target level for any "local" activity (load, generate, build) is determined during the initial connection of the project to Code Pipeline and can by modified via the project's Code Pipeline properties.

git_ispw_life_cycle_1.png

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*