Context
We have a C# project, hosted in Azure devops.
We have a pretty standard workflow :
build + unit tests,
manual QA,
then mark the built artifacts as "validated by QA".
These artifacts are then made available to our deployment team.
Since our product is deployed on our clients' premises, the actual deployment will not be triggered from the azure pipeline.
Situation
So far, we work with a build job, and we communicate with the deployment team by sending a notification : "build 345 is validated, use that one for deployment".
The problem is : they basically have access to the list of all builds, including the ones which were built correctly, but where QA found a bug for example.
What I would like to have
Give the deployment team access to a section where only validated builds are published.
This could be :
using a release pipeline : let the result of the release pipeline be to offer the artifacts for download
but I did't find an action which just states "publish the artifacts"
in the build pipeline, keep the builds in a "not yet completed" state, and wait for a manual action of the QA team to flag them as "success" or "failure".
I don't see a way to add a manual step to a "Build" job (and I think this would be a bad setup for a build job anyway)
Question
What would be the prefered way to represent this workflow in azure devops ?
Then you could have a release pipeline with only these tasks:
1. Manual intervention Sends an e-mail to the QA-team telling them to do their thing with build x.y.z. When the build is approved for release, someone from the QA-team signs into Azure Devops and lets the release resume.
2. Notification E-mail or whatever notification you're using goes out to the deployment team, informing them about the newly approved build.
Related
I'm working on a project where we have a front end application. This application has a second entry point I've added for our login application. So I've started setting up a new pipeline for building it. Upon a successful build & push of the login-app artifact I want the login server to also trigger a build. The backend .net app for the login server will serve the built angular app from its public folder, so hence the reason to trigger the pipeline.
In each of the repos we have three branches that we deploy from: qa, uat, and prod. So when a qa build runs for the frontend, I want the qa branch of the login server to run. Same with uat -> uat and prod -> prod. Based on the information here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops#branch-considerations it doesn't sound like I can use the pipeline triggers for this. Is there another approach we could take?
If you don't use pipeline completion triggers in yaml, you could consider to use build completion trigger(Classic).
In the other hand, you could install external free extenion: Trigger Build Task or Trigger Azure DevOps Pipeline, so there will be additional available task to trigger a new build when this build is done.
Of course, you could directly use Rest API: Builds - Queue to queue a build.
We have dozens of code repositories in Azure DevOps, and we're working on a major release strategy.
We have a stable development branch called develop, where code has been tested and peer-reviewed, with features approved by QA. All of our service repositories have a similar structure.
We want to "click a button" and branch from develop across all our repositories to a release candidate branch, that QA can regression test as a complete system... basically a "snapshot" of what we expect is ready for release. We would then build from this code base, release to our QA environment from the corresponding builds, and when certified, deploy to production, then smoke test and merge the release candidate branch into master, then master back into develop.
It doesn't seem like there's an easy way to manage multiple builds or releases in Azure DevOps though. Atlassian's Bamboo supported this concept of "meta builds" but I don't see a way to do this in Azure DevOps. I can't seem to even create a build that is not implicitly linked to a single repository.
How can I automate this and get this workflow working in Azure DevOps?
You can use a Build Task from the Marketplace that queue a new build: the first two found are Trigger Build Task and Build Chain.
You defined an overarching build that queues the single ones and does any additional work.
I am trying to add Azure Pipelines configuration to an existing project, bundler/bundler. Here is the PR that adds the configuration:
https://github.com/bundler/bundler/pull/6899
As one of the maintainers set up the bundler/bundler project on Azure Pipelines, this PR already triggers a build:
https://dev.azure.com/bundler/bundler/_build/results?buildId=11
Note that the build has a green checkmark and is marked as finished.
(Also note that there are loads of tests failing in the build, as this wasn't tested on Windows before. To make the build succeed anyway - and not all PRs and commits get the red "x" on Github while I am working on fixing the tests, I added || exit 0 at the end of the test command - which works fine on Azure Pipelines)
A feature of Azure Pipelines' GitHub integration is that the build results are shown in Github via a feature called "Check":
https://github.com/bundler/bundler/pull/6899/checks
(A shorter version of that is also included at the end of the PR page: https://github.com/bundler/bundler/pull/6899#partial-pull-merging)
Unfortunately, this check doesn't reflect the build status on Azure Pipelines and is still shown as "in progress":
and
Any idea why the GitHub check doesn't reflect the build status on Azure Pipelines?
What is confusing me further, is that the integration with Azure Pipelines actually worked just fine (check correctly reflects the build status) in the Pull Request that was automatically created by Azure Pipelines when creating the bundler/bundler project: https://github.com/bundler/bundler/pull/6955
But: It also can't really be the Azure Pipelines configuration I created in my PR, because the same configuration also works just fine in my fork: https://github.com/janpio/bundler/pull/6#partial-timeline (see the green checkmark for the bundler task). (On the other hand: Here Azure Pipelines doesn't use the "Check" feature of Github at all)
Great question. The most likely reason is that there some was glitch in the communication between Azure Pipelines and GitHub. It's very rare but sometimes a webhook between GitHub and Azure Pipelines doesn't trigger. There's no way to tell why it happened; it could have been a fault on either side.
Unfortunately, there's no way to re-send a webhook that didn't get delivered. Your only recourse is to rebuild that pull request. If you select the "Rebuild" option (in the ... menu):
Then a new build will be queued and, when it finishes, the status update will be sent back to GitHub. The check in the pull request will then be updated.
A less likely (but definitely possible) reason is that there's a bug in either Azure Pipelines or GitHub. And in this particular case, there was a bug with the code that uploads test results from Azure Pipelines to the test case manager API.
(Thanks for reporting the issue, we're sorry that we had a bit of a problem here, but we're glad that we were able to resolve this.)
Setting the following configuration worked for me:
I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.
Here's what I'd like:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.
The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.
I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).
Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?
I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.
Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.
I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage
The stages can then have approvals on them as well.
I'm using Visual Studio Team Services (VSTS), previously known as Visual Studio Online (VSO) to build a Continuous Delivery pipeline. My goal is to follow as close as possible the Continuous Delivery book from Jez Humble and David Farley.
I would like that when a stage (named Environment in VSTS) fails, a notification (an email) is sent to every developers involved in this release. This notification would say either :
You broke the stage (Regression)
The stage was already broken (Failed)
You fixed the stage. (Fixed)
Currently, only the person who created the release manually (or by pushing the commit which triggered the build and after that the release) will receive this email and without the information I want.
I've played a little bit with VSTS API, and can get the associated commits (and the developers email) for a given build (but not for a given release) :
$token = "vsts token"
$endpoint = "https://acme.visualstudio.com/DefaultCollection/MyProject/_apis/build/builds/42/changes?api-version=2.0"
$b64creds = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$($token):a"))
$changes = Invoke-RestMethod -Headers #{Authorization="Basic $b64creds"} $endpoint
$changes.value | ForEach-Object { $_.author.uniqueName }
I've seen that in VSTS interface, you can see which commits were added between 2 releases. It's very close of what I want even if I didn't found this information in the API. But even with this information, a same release definition is used for all branches of my project, so for example Release-26 will be a feature branch and Release-27 will be develop. It doesn't make sense to compare these 2 releases.
I know that I can get the build ID in a release stage from the environment variable, and after that use my script above and create a PowerShell Task or a Webservice plugged on VSTS. But it will only work if a release is triggered for each build, which is not always the case.
Do you know a (better) way to send this notifications with VSTS ?
And do I use the right tool for that sort of things ?
You can only send the email alert to "Environment owner" & "Release creator" and there isn't any way to customize the content in the email alert for now, you can submit a feature request on VSTS User Voice.
Rest API is a good tool to get these information. But you mentioned that you are using the same release definition for all branches. This does not make sense. Different branches refer to different version of your project, why do you deploy all of them in one release pipeline? If you configure your workflow to one release definition per branch, the resolution would be more easy. You just need to get the Build ID for previous release, and then get the changes after that build. And you can also add a powershell task to create a lable/tag for TFVC/Git repositories for current release version so that you can get the changes between the labels/tags.