Pull request and merge actions in CI/CD

Question

The CI/CD pipeline supports pipelines per branch but no pipeline for feature branches is triggered automatically. There are pipelines deployed for the following branches: development, master. The respective pipeline is triggered onCommit event (codeCommitRepo.onCommit('OnCommit', {}) so whenever there is any code push to the branch. We are planning to use git-flow as the branching strategy but don't exactly see the advantages of having another branch called staging, in addition to development, master.

1. Is there a use of having a third branch like "staging" when using CI/CD?

The CI/CD pipeline looks as follows:

2. At what stage should the PR from the feature branch be created?
3. At what stage should the PR be merged into the development branch?
4. At what stage should the PR from the development branch to master be created?
5. At what stage should the PR be merged into the master branch?
6. What if the development pipeline fails? Should the code be manually unmerged to get development back in the stable condition?
7. What if the master pipeline fails? Is the code being merged in the branch after the pipeline succeeds?

I would like to understand what the flow should look like starting from a feature branch. (P.S: Not interested in Trunk based development strategy)

Also, the pipeline is coming from https://github.com/awslabs/aws-simple-cicd and is written using AWS-CDK

Answer 1

1. In my opinion there should be a staging branch , which holds the production candidate code.And instead of a Test env , have a staging env which will be complete replica of Prod env. In the Staging env the QA can perform their testing and other checks.

• Dev env = only for developer.
• Stage env = Replica of Prod and holds production candidate build/code , where QA can perform their testing and simulate Prod.

Having a Staging branch has its benefit as you can have code which will merge to master and deploy to prod , and the developer can experiment/work on develop branch without worrying of any accidental merge to master directly.

2. Once someone completes a feature or fixes a bug/error or implementation is done and testing needs to be performed.

3. same as above.

4. Once the code has been passes the test's and QA verified on staging env and No new feature are to be added to Prod , it can be merged to master.

5. No new feature are to be added to Prod , QA passed and test cases passed, it can be merged to master

6. That's where the Staging branch will help , as even if code fails on stage as it is supposed to be complete replica of prod env. we can revert or commit the fix again without worrying of our master branch.