Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/adampaternostro/azure-dev-ops-single-ci-cd-dev-to-production-pipeline
Create a single CI-C pipeline
https://github.com/adampaternostro/azure-dev-ops-single-ci-cd-dev-to-production-pipeline
azure azure-devops azure-functions devops vsts
Last synced: about 1 month ago
JSON representation
Create a single CI-C pipeline
- Host: GitHub
- URL: https://github.com/adampaternostro/azure-dev-ops-single-ci-cd-dev-to-production-pipeline
- Owner: AdamPaternostro
- Created: 2018-10-02T19:23:20.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2018-10-02T20:52:52.000Z (over 6 years ago)
- Last Synced: 2024-07-29T17:04:50.475Z (6 months ago)
- Topics: azure, azure-devops, azure-functions, devops, vsts
- Language: C#
- Size: 866 KB
- Stars: 8
- Watchers: 1
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Azure-Dev-Ops-Single-CI-CD-Dev-To-Production-Pipeline
A common pattern I have seen customers implementing in their DevOps strategy is to have two separate pipelines for Dev and QA-Prod. Their Dev pipeline is full CI/CD process, so each source control check-in triggers a build which then triggers their release pipeline. The Dev pipeline only has one stage named Dev and an entirely separate pipeline exists for QA/Production. The main reason I have heard for having two pipelines (versus just one), is that customers are worried a check-in to source control will mistakely be deployed to QA/Production. Also, customers with approvals in their pipelines do not want to "reject" all the Dev releases that have no change of making it past Dev. Here is how I deal with the issue.
## Ideal build/release pattern:
1. Code is checked into source control
2. A build is automatically started and the code is compiled
3. When the build completes (successfully) the release pipeline is started
4. The new code is pushed to Development
5. Once the code is verified, the new code is approved for a QA release
6. Once the QA release is verified, the new code is approved for a Production release
## The Issue:
If you have lots source control check-ins throughout the day, you get the above steps executing each and every time, but you really do not want to reject the code to prevent a release to QA for each check in. Your approval person will probably get pretty annoyed.
## What I have seen:
Customer will build two pipelines.
1. Dev: Steps 1 through 4 from above still apply, but there is no link to QA.
2. QA-Prod: Steps 5 and 6 are put in a different pipeline which needs to be kicked off. And even worse I have the QA/Prod piepline rebuild the code. You should only build your code once! Building for Dev and then building for QA-Prod introduces possible issues.
## The solution
1. Implement the Ideal pipeline
2. In Step 5 add the following:
1. Keep our normal approval process to QA
2. Add a Gate
3. The Gate will wait until the Build has a Build Tag applied (this is a tag on your build, not your source control)
4. Once the Build tag is applied the release will continue
5. The approval to QA is performed and everything works as normal
### How to setup the build tag gate
1. Copy the Azure Function that is in this repository and deploy
2. Click on the Pre-Deployment Conditions for QA
3. Add your approvers
4. Add a Function Gate
5. In the Body enter:
```
{
"personalAcccessToken": "$(personalAcccessToken)",
"organization" : "$(organization)",
"project" : "$(build.projectname)",
"buildId" : "$(build.buildid)",
"requiredTag" : "$(requiredTag)"
}
```
6. Create variables for personalAcccessToken, organization and requiredTag
1. personalAcccessToken = you will need to generate a PAT token
2. organization = this is part of your url
3. requiredTag = this is the tag to test on your build (e.g. ApprovedForRelease)
7. For the Success Criteria enter: eq(root['status'], 'successful')
8. Under Evaluation Options select "On Successful Gates, ask for approvals" (we want the gates to execute first, before approvals).
9. You should set how long you want this gate to re-try. This depends on how long you typically wait between a dev release and you push to QA.
10. You also need to set the number of parallel deployments for the QA stage to Unlimited. This means we will have many release pipelines attempting to release to QA at the same time. So, once a build is tagged that release will move forward. You have to be aware that tagging a bunch of builds at the same time would trigger many releases to QA simultaneously.
#### QA Gate approvals
#### QA Function Gate
#### QA Deployment Queue Settings
#### QA Gate failure since Build is not Tagged
#### Tagging the Build
#### QA Gate passed, waiting for approvals
