I have a release pipeline set up dev qa and prod. QA and PROD triggers are set to after stage with pre-deployment approvals set up
Problem I facing I have feature which I broken into 3 sprints ( user stories ) after each sprint all dev work is deploy to dev for testing. After dev is deployed the email going out to pre-deployment approvals for QA which is not what I need
Solution I looking for is each sprints get deployed to dev. When I am done with the whole feature I can add a message and click a button or something then the email must go out to the pre-deployment approvals can this be done using triggers are set to after stage?
You could set a post-deployment approvals for dev stage, after deployment for dev stage is finished, it need approval before the release is triggered to other stages. After you approve the post-deployment approvals for dev stage, the email for pre-deployment approvals will send.
Related
I use Azure pipelines to deploy to different environments (dev, test, prod) that have been running for 2 1/2 years without issue.
Recently the pipeline has stopped asking for 'approval' after the test deployment stage.
It has been working with the following steps for 2.5 years
Build
Deploy to 'dev' without approval
Wait for manual approval
Deploy to 'test'
Wait for manual approval
Deploy to 'prod'
The Azure pipeline is a template within a separate repo - there have been no changes to the .yaml files but now the process is
Build
Deploy to 'dev' without approval
Wait for manual approval
Deploy to 'test'
Deploy to 'prod'
This behaviour is mirrored on every service that deploys using this template.
I am at a loss as to what is causing this
The solution was this:
I 'environment' production had lost its approval - adding it back did not work.
So deleted and recreated and excepted the loss of deployment history. Working now.
Why this would happen I do not not know
I am working with 3 pipes based off 3 different repos within Azure DevOps. All 3 pipes deploy to the same cloud VM and all 3 have a set of E2E automated tests which are run after the deployment stage. I am currently having issues where 1 pull request is completed kicking off a deployment, then while the E2E tests are running a different pipe is kicked off, this causes services to stop on the VM during deployment making the E2E tests fail unusually.
Can I setup my pipe to only start a deployment + test if no other builds are already running against the target VM?
Cheers
If these stages in release pipeline are set to run one after another, there will be no issues.
However, new push will trigger a new release and break the ongoing deployment, we suggest that you review this doc: Release gates and approvals overview, so you can try to set up release deployment control using gates or define approvals and checks.
I have an application with .NET Core web API and Angular client application which is hosted in Azure as app services. Trying to introduce full DevOps practice to this up until production.
I'm trying to create a release pipeline in Azure DevOps while keeping git-flow as my branching strategy. currently,
I have 5 different environments which are Dev > QA > UAT > Pre-Prod > PRODUCTION.
I know with a trunk-based approach this is pretty easy to configure with one release pipeline which will go through all the environments as one release until it goes to production. In the current setup, this is automated only up to the UAT environment using Only the Development branch as the release pipeline which works pretty well.
I'm wondering what would be the most suitable way to do it keeping git-flow as my branching strategy. Also, relevant branches should automatically tag with UAT and production releases.
Mainly I have a development branch that contains the latest development activities and feature branches will be merged into development after PR approvals and Master is the production equal branch.
With my current environments setup, releasing this to UAT is quite simple with the Development branch but when proceeding to Production it might cause problems.
To keep the question short considering multiple factors, I was planning to have 3 different pipelines as follows
UAT - One release pipeline from development which goes through Dev > QA > UAT
Prod - Master branch will be configured with this pipeline which goes through Pre-Prod > Prod environments. this will be a separate build pipeline which will trigger soon after development merges with the master branch. this will be the main production pipeline. either this could be a master or separate release branch.
Hotfix - This will be the Production hotfix release pipeline with a separate build pipeline which goes through QA > Pre-Prod > Prod.
Will this approach works or any bettor way of doing this. Since this is the very first time planning release it to production through the pipeline. I would like to hear advice from experts?
we've got a GitLab CI build / test / deployment pipeline and need to insert a manual approval between deployment to Test and promoting to Prod. I can't figure out how to do that.
Ideally we would like to have a button like in GoCD or in AWS CodePipeline. However for our current project we use GitLab EE (ver 12.3.5-ee) hosted on our servers, not using gitlab.com, but I guess the .gitlab-ci.yml should be the same.
This is a part of my current .gitlab-ci.yml:
stages:
# lint, build, test, ...
- deploy_test
- approval
- deploy_prod
deploy_test:
stage: deploy_test
only:
refs:
- prod
script:
...
wait_for_approval:
stage: approval
# how do I do this???
deploy_prod:
stage: deploy_prod
only:
refs:
- prod
script:
...
Any idea?
Use when: manual in your stage.
To be sure the manual action is blocking (and no optionnal), add also allow_failure: false (is set to true by default)
More info in the documentation
Note : if you created the stage only for the approval, I could advice you to remove it and put the when: manual in the deploy_prod stage.
deally we would like to have a button like in GoCD or in AWS CodePipeline
In addition, of when:manual, you also have GitLab 14.9 (March 2022), which comes with (still for GitLab Premium/Ultimate only):
Deployment Approval on the Environments page
We are excited to introduce the Deployment Approval capability in the GitLab interface. In GitLab 14.8, we introduced the ability to approve deployments via the API.
Now, deployment approvers can view a pending deployment and approve or reject it conveniently directly in the Environments page. This update continues our work to enable teams to create workflows for approving software to go to production or other protected environments.
With this update, we are now upgrading the feature to beta.
See Documentation and Issue.
And GitLab 14.10 (April 2022) comes with:
Multiple approval rules for deployment approvals API
Previously, deployment approvals supported a simple model where the ability to execute a deployment and approve a deployment were both controlled with a single list of users.
With this update, you have more flexibility and granularity with these rules and can specify multiple levels of control using the API.
One type of model that can now be supported is where there is separation of duties between deployment executors and approvers in your organization.
Another supported model is where approval is needed separately from multiple levels, such as a QA tester group and a security group.
See Documentation and Issue.
You can combine that with GitLab 15.2 (July 2022) which adds (non-CE editions only):
Group-level UI for protected environment settings
Previously, if you wanted to configure group-level settings for protected environments, you had to use the API.
With this release, you can now view and edit these settings in the UI.
This change allows you to more easily set policies for which users and groups can deploy to environments across projects within a group.
See Documentation and Issue.
I understand that VSTS Release is still not under final version, but I am stuck with a problem. When there is a pending approval, sometimes it is simply not possible to approve/reject the release. Example:
As you can see I have 3 environments: DEV, QA and PROD. When deploying to DEV, there is no approval required. So now it shows "In Progress" but an approval is waiting.
On the picture above is a proof that we are waiting for the Post deployment approval.
Finally, you can see above that I configured myself to receive notification for approval and to be an approver.
Any idea?
[UPDATE]
The above shows that I could approve pre-deployment to QA (DEV here was auto-approved), and now I cannot approve the post-deployment to QA.
Here is a screenshot of a successful release (only on DEV environment though), and having the same warning message:
Cannot update deployment status for (web app name) -
{"Message":"Repository could not be found."}
You need to go into the release and cancel all previously queued releases. In your first screenshot under environments, each environment should be a hyperlink. Select that one in question and under Waiting for Deployment, you can cancel all the ones you don't want. That will clear up the queue.
When we have a prior release candidate that we are not going to deploy to prod, it looks like this:
Note this is in the new Azure DevOps UI for VSTS/TFS builds and releases. This shows, chronologically from the bottom up, two releases deployed to prod, then a third release not deployed to Prod, then a fourth release (at top), which cannot be deployed to prod until the third release is rejected or cancelled. Both will work but in my experience the release tracking is a little cleaner if you reject the release rather than cancel it.
To do this, click "Pending approval" in the third release Prod environment to view approvals and then click Reject. If you have multiple prior releases not deployed to Prod you will need to reject or cancel them all - again my preference is to reject them chronologically (from first undeployed release near the bottom towards the last undeployed release near the top).
Once done, the release at the top will no longer appear as queued and you will be able to approve it (assuming you have enabled Pre-deployment approvals for approving deployment to Prod) to allow deployment to commence.