I have been looking for implementing deployment approval within bitbucket pipeline. Basically it's similar to Octopus deploy you can implement 'awaiting for approval' step. Has anyone ever implemented it with bitbucket pipeline ?
Yes, you can trigger steps manually by specifying trigger: manual in your step.
See the docs for more information
Related
I have a Develop branch and Master. My task is to trigger the build pipeline when I create a Pull Request from Develop to Master before merge, depends on Develop branch. The trigger should be from source branch. Can we add tags to trigger the build pipeline based on source branch. I am using classic pipelines and new to ADO. how can I achieve this. Please someone help me to achieve this in detail.
To get a pipeline to trigger when a PR is opened but before it is merged you would need to add a branch policy on master branch to have a build validation step. This will trigger the pipeline to run whenever a PR is opened to master
Build Validation
Unfortunately, PR trigger behaviour varies, depending on which SCM you're using: Azure Repos Git, GitHub, or Bitbucket Cloud. With BB Cloud, the PR build will be triggered when the PR is opened or updated, but not when it is merged. The filter input can be used to specify branches for PR trigger.
Details for each SCM system can be found by clicking on the links on the "Triggers in Azure Pipelines" documentation.
The way how to set that up does depend on your source-code version control software you are using. For GitHub you need to install the "Azure Pipeline" GitHub App.
Then configure a pipeline in AzureDev Ops and enable "Continous integration" in "Triggers" section.
P.S.: To avoid that the compile check of a PR will result in published artefacts you can either have to different pipelines or - that's what I try to achieve - one pipeline where the artefacts are just being generated when the PR is merged.
I've been looking into Azure DevOps and I'm puzzled by something: Microsoft seem to be strongly recommending the use of YAML pipelines instead of classic ones; fair enough, but they need to replace all the functionality that was in classic pipelines. How am I meant to replace the "release pipeline" functionality with YAML pipelines?
So for example, with classic release pipelines, I could setup a pipeline to deploy to production that had a manual trigger (see 'Manually by a user'):
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops#pull-request-triggers
What's the YAML pipeline equivalent to this? I obviously don't want a trigger that automatically deploys to production - I always want that deployment to be initiated strictly manually - but the help article doesn't seem to provide any YAML alternative.
As Daniel comments above, Yaml pipeline supports multi-stage yaml pipelines for CD. You can check Azure DevOps Pipelines – Multi-Stage Pipelines and YAML for Continuous Delivery for more details.
Azure devops yaml multi-stage pipeline and classic release pipeline can both be used for CD, however they do have some difference. And as I know no feature in YAML pipeline can be equivalent to the manual trigger in Classic Release.
For now the manual trigger is not supported in YAML pipeline, see this discussion. Good news is that the Product team has considered the feature request and the new feature is on Roadmap. (Perhaps on plan for 2020 Q3)
According to the team there: The scope of new feature they are thinking here is to be able to mark a stage as "always start manually". If there are other stages that depend on this stage, then those would continue to wait till this stage has executed.
We may have to wait for some time before the manual trigger feature comes true in Yaml pipeline. Hope the new feature would meet your needs.
Microsoft says that their teams internally use Release Flow branching strategy: Release Flow: How We Do Branching on the VSTS Team
Release Flow means that the release branch has to be created to make the release triggered, which can look this way:
releases/productname-sprint02
Therefore, creation of a such branch can act as the manual trigger
In multi-stage YAML pipeline the production deployment stage should be coded to be triggered when the pipeline execution is the release branch context, which is not hard to do using a condition: and an expression that contains a check:
${{ startsWith(variables['Build.SourceBranch'], 'refs/heads/releases')
p.s. My recent blog on the similar subject: Azure DevOps – YAML pipelines and branching strategies
I have recently moved from Classic release to YAML release pipeline. With Classic release I would simply trigger manually the deployment I was interested in (Dev, Integration, UAT or Production).
However with YAML pipeline I use stages and they are triggered automatically after building. To prevent that, I've added Approval guard on the Integration stage as shown below.
However the pipeline was running indefinitely and would never end. So I've set a 5 minute timeout on approval and now the Integration stage is marked as Skipped if nobody approves.
I feel I'm not doing it the right way as it is quite different from classic release.
Is this the correct way to handle release pipeline when using YAML ?
Is this the correct way to handle release pipeline when using YAML ?
Yes, you are on the correct way (At least for now).
Just as you said in the question, Azure devops does not support manually triggered stage(s) in YAML multi-stage pipelines. So, we could not simply trigger manually the deployment stage we are interested in.
There is an On Roadmap user voice about this request:
Manually triggered stage(s) in YAML multi-stage pipelines
You can look forward to it, and I believe it will meet us soon.
So, your workaround is correct for now.
I have a java application and am trying to use Azure DevOps to build and deploy. Am able to do a build and publish the artifact in the build pipeline. In the release pipeline, I stages (dev/train/prod) in each stage I have a maven task to detokenize the build specific to the environment which I am able to do but I want to publish it as a artifact similar to the one in build pipeline. Is there any task to do that or any other alternate approach?
Can we publish artifacts in release pipeline - Azure devOps?
Sorry for any inconvenience.
This behavior is by designed and MS replied they don't have plans to support uploading folder/artifacts from release in near future.
When you check the document Publish Pipeline Artifacts task, It stated that:
Use this task in a pipeline to publish artifacts for the Azure
Pipeline (note that publishing is NOT supported in release
pipelines. It is supported in multi stage pipelines, build
pipelines, and yaml pipelines).
And if you check directly code that is executed, then you can see the Publish Pipeline Artifact task works only for Build pipelines.
You could check this ticket on github for some more details, many communities are waiting for publish artifact from release pipeline.
So, I helped you add a request for this feature on our UserVoice site, which is our main forum for product suggestions:
https://developercommunity.visualstudio.com/idea/823829/support-publish-artifact-from-release-pipeline.html
You could vote and add your comments for this feedback. When there are enough communities vote and add comments for this feedback, the product team member will take this feedback seriously.
Hope this helps.
I was facing the same problem: I wanted to upload artifacts in a release pipeline and in a later agent phase download those artifacts again.
Based on some answers from a related SO Post I created an Extension that offers the possibility to:
Upload a file or a folder to the Release Logs
Automatically download an Artifact from the logs that was previously uploaded
The upload task is making use of the built-in logging command to add files to the Release Logs. The download task then queries the Azure DevOps REST Api to download all logs collected thus far, tries to find the specified artifact and copies it to a specific place.
If anyone is interested, it can be found on the Marketplace
My source code is on GitHub.
I have an Azure Devops pipeline set up to build and deploy the application to an Azure subscription.
I also have the full azure environment defined in ARM templates.
I'd like to run the template deployment only when a specific folder changes in my GitHub repo.
Path triggers are only for Azure Devops repos.
Other possible solutions I investigated, but there is no clear documentation on how to achieve this exactly:
Custom condition on build or release task.
Pre-deployment conditions. Maybe artifact filters?
Pre-deployment Gates?
The ARM template deployment is idempotent, I know, but it takes a several long minutes to run even if there was no infrastructure change and I'd like to avoid that time wasted on every build.
Sounds like you have a single pipeline for both the infrastructure and application code. I have separate pipelines for each, one for infrastructure as code and other builds/pipelines for applications, NuGet package creation, etc. Perhaps split the pipeline and have the application deployment trigger after and separately from the infrastructure deployment pipeline. That way the application build and deployment can run in a more frequent cycle.