Skip to end of banner
Go to start of banner

[Shift-left] GitLab branching strategy

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This sequence diagram illustrates the process of continuous integration and deployment (CI/CD) within a project. The main participants are developers, automated quality assurance (AQA) engineers, and different branches of the project’s repositories, as well as the continuous integration environments.

Participants:

  • Developer: A person who develops new features or fixes for the project.

  • AQA: The Automated Quality Assurance engineer responsible for writing and managing test cases.

  • mod-a Branches: The branches of the mod-a repository (feature, development, staging, and master).

  • Karate Branches: The branches of the Karate test framework (feature, development, staging, and master).

  • Cypress Branches: The branches of the Cypress test framework (feature, development, staging, and master).

  • platform-complete Branches: The branches of the platform-complete repository (development, staging, and snapshot).

  • CI QG Environments: Continuous Integration Quality Gate environments for Karate and Cypress (development, staging/master).

Workflow:

  1. Feature Development:

  • The Developer pushes new feature code to the mod-a feature branch and new tests to the Karate feature branch.

  • The AQA engineer pushes new feature tests to the Cypress feature branch.

  • The Developer notifies the AQA engineer about the feature merge.

  1. Merging Feature to Development:

  • The mod-a feature branch is merged into the mod-a development branch.

  • Jenkins updates the install.json file in the platform-complete development environment.

  • The Karate feature branch and Cypress feature branch are merged into their respective development branches.

  1. CI Quality Gate - Development:

  • The platform-complete development branch triggers the CI Quality Gate process.

  • Karate and Cypress environments are deployed for the platform-complete development branch.

  • Both Karate and Cypress tests are run in parallel in the development environment.

  • Feedback from the test runs is sent back to the Developer.

  1. Cherry-pick and Merge to Staging:

  • Feature code from the mod-a development branch is cherry-picked into the mod-a staging branch.

  • Jenkins updates the install.json file in the platform-complete staging branch.

  • Feature tests from the Karate and Cypress development branches are cherry-picked into their respective staging branches.

  1. CI Quality Gate - Staging:

  • The platform-complete staging branch triggers the CI Quality Gate process.

  • Karate and Cypress environments are deployed for the staging stage.

  • Both Karate and Cypress tests are run in parallel in the staging environment.

  • Feedback from the test runs is sent back to the Developer.

  1. Final Merge to Master and Snapshot Creation:

  • The mod-a staging branch is merged into the mod-a master branch.

  • Jenkins updates the install.json file in the platform-complete snapshot environment.

  • Feature tests from the Karate staging branch and Cypress staging branch are merged into their respective master branches.

  1. CI Quality Gate - Snapshot:

  • The platform-complete snapshot branch triggers the final CI Quality Gate process.

  • Karate and Cypress environments are deployed for the platform-complete snapshot branch.

  • Both Karate and Cypress tests are run in parallel in the platform-complete snapshot environment.

  • Feedback from the test runs is sent back to the Developer.

Summary:

This process ensures that all new features and test cases are thoroughly tested at each stage of development, from the initial feature branch to the final snapshot, before being deployed to production. The diagram shows how the development and testing branches are systematically merged and tested, ensuring high-quality code is maintained throughout the development lifecycle.

  • No labels