<ol>
<li>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.</li>
</ol>
<ul>
<li>Dev env =  only for developer.</li>
<li>Stage env =  Replica of Prod and holds production candidate build/code , where QA can perform their testing and simulate Prod.</li>
</ul>
<p>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.</p>
<ol start="2">
<li><p>Once someone completes a feature or fixes a bug/error or implementation is done and testing needs to be performed.</p>
</li>
<li><p>same as above.</p>
</li>
<li><p>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.</p>
</li>
<li><p>No new feature are to be added to Prod , QA passed and test cases passed, it can be merged to master</p>
</li>
<li><p>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.</p>
</li>
</ol>

CC BY-SA 4.0
2020-11-24T13:15:21.400Z
2020-11-24T13:15:21.400Z
vasurb
<p>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: <code>development</code>, <code>master</code>. The respective pipeline is triggered <code>onCommit</code> event <code>(codeCommitRepo.onCommit('OnCommit', {})</code>  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 <code>staging</code>, in addition to <code>development</code>, <code>master</code>.</p>
<ol>
<li>Is there a use of having a third branch like &quot;staging&quot; when using CI/CD?</li>
</ol>
<p>The CI/CD pipeline looks as follows:
<a href="https://i.sstatic.net/fYixY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/fYixY.png" alt="enter image description here" /></a></p>
<ol start="2">
<li>At what stage should the PR from the feature branch be created?</li>
<li>At what stage should the PR be merged into the development branch?</li>
<li>At what stage should the PR from the development branch to master be created?</li>
<li>At what stage should the PR be merged into the master branch?</li>
<li>What if the development pipeline fails? Should the code be manually unmerged to get development back in the stable condition?</li>
<li>What if the master pipeline fails?
Is the code being merged in the branch after the pipeline succeeds?</li>
</ol>
<p>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)</p>
<p>Also, the pipeline is coming from <a href="https://github.com/awslabs/aws-simple-cicd" rel="nofollow noreferrer">https://github.com/awslabs/aws-simple-cicd</a> and is written using AWS-CDK</p>

<amazon-web-services><continuous-integration><continuous-deployment><continuous-delivery><aws-codepipeline>
Pull request and merge actions in CI/CD
systemdebt
# Pull request and merge actions in CI/CD

(Asked by: username_0 on 2020-11-22)

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:
[![enter image description here](https://i.sstatic.net/fYixY.png)](https://i.sstatic.net/fYixY.png)

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

**Tags:** amazon-web-services, continuous-integration, continuous-deployment, continuous-delivery, aws-codepipeline


---

## 1 answers

### Answer by username_1 on 2020-11-24. Score: 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.


---

