<p>If using AWS CodeCommit, you can create an event in AWS event bus that can trigger the CodeBuild/CodePipeline:</p>
<pre><code>{
  &quot;source&quot;: [&quot;aws.codecommit&quot;],
  &quot;detail-type&quot;: [&quot;CodeCommit Repository State Change&quot;],
  &quot;detail&quot;: {
    &quot;event&quot;: [&quot;CreateBranch&quot;],
    &quot;referenceName&quot;: [{
      &quot;prefix&quot;: &quot;release/&quot;
    }]
  }
}
</code></pre>
<p>I'm pretty sure the same can be done also using Github/Bitbucket webhooks</p>

CC BY-SA 4.0
2024-05-12T12:31:33.750Z
2024-05-12T13:46:39.050Z
2024-05-12T13:46:39.050Z
Oleg
<p>We have a system set up that when we merge a branch into master, it runs in AWS CodePipeline where it recognizes the merge, builds the code to our QA environment, then waits for approval to be deployed to production.</p>
<p>The issue is that once we make that first merge into master we are gatekept from releasing anything in production until everything is tested.</p>
<p>Is there a way to have a process in AWS CodePipeline where it can recognize a new branch has been pushed to Git, something like a %Release% branch, that can be picked up and deployed to QA only, so in case we need to run a hot fix to production we can do that with out worrying about untested changes in QA?</p>
<p>My thought was creating a new pipeline that we call qa-testing-pipeline along side of our main-pipeline, then that pipeline only build and deploy to qa. This would mean that if we needed to build something to master, we could do that, and run our main-pipeline deployment which would deploy to QA, overwriting the existing build, then on approval go to production.</p>
<p>For this image, the QA Environment is the same in both pipelines. We would just like something that doesn't gate keep us from a hotfix until the current release is ready.</p>
<p><a href="https://i.sstatic.net/82Ca6ENT.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/82Ca6ENT.png" alt="enter image description here" /></a></p>

<amazon-web-services><cicd><aws-codepipeline>
AWS CodePipeline Handling Release Candidates
Travis
# AWS CodePipeline Handling Release Candidates

(Asked by: username_0 on 2024-05-08)

We have a system set up that when we merge a branch into master, it runs in AWS CodePipeline where it recognizes the merge, builds the code to our QA environment, then waits for approval to be deployed to production.

The issue is that once we make that first merge into master we are gatekept from releasing anything in production until everything is tested.

Is there a way to have a process in AWS CodePipeline where it can recognize a new branch has been pushed to Git, something like a %Release% branch, that can be picked up and deployed to QA only, so in case we need to run a hot fix to production we can do that with out worrying about untested changes in QA?

My thought was creating a new pipeline that we call qa-testing-pipeline along side of our main-pipeline, then that pipeline only build and deploy to qa. This would mean that if we needed to build something to master, we could do that, and run our main-pipeline deployment which would deploy to QA, overwriting the existing build, then on approval go to production.

For this image, the QA Environment is the same in both pipelines. We would just like something that doesn't gate keep us from a hotfix until the current release is ready.

[![enter image description here](https://i.sstatic.net/82Ca6ENT.png)](https://i.sstatic.net/82Ca6ENT.png)

**Tags:** amazon-web-services, cicd, aws-codepipeline


---

## 1 answers

### Answer by username_1 on 2024-05-12. Score: 0

If using AWS CodeCommit, you can create an event in AWS event bus that can trigger the CodeBuild/CodePipeline:
{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "detail": {
    "event": ["CreateBranch"],
    "referenceName": [{
      "prefix": "release/"
    }]
  }
}

I'm pretty sure the same can be done also using Github/Bitbucket webhooks


---

