I have a YAML pipeline in Azure DevOps that contains a list of variables which I can choose which on of them to use in runtime.
This is my code:
And this is how it looks in runtime:
My question is how to create this option in a classic Azure pipeline?
From past threads I read I saw that there's no option to do that, but maybe something changed lately.
Not Possible with Classic Release Pipeline.
Related
I have pipeline and I deployed azure functions from it and I want to disable the pipeline for few days and reenable when I use it
Not only azure functions you can create any pipeline, but you can also disable and re enable it whenever required
Under pipeline settings you can find the options of deleting the pipeline
I have an Azure Repos project with IaC code and ci/cd yaml pipelines to set up Azure Synapse infrastructure. Can you recommend what is right approach when I integrate the workspace to connect to git? Should I create a new project in Azure Repos for the Synapse artifacts or should I use the same repository as the infrastructure project?
I will be setting up ci/cd pipelines to deploy the azure synapse artifacts as well.
Thanks!
Here's an answer to a similar question I posted:
You'll want to follow Microsoft's guide on CI/CD with Synapse. This is a great walkthrough video for the process.
Work in your development environment and commit to your collaboration branch.
A pipeline triggers off of your workspace_publish branch, releasing your code to your next environment (preferably with an approval gate)
Continue releasing the same code to higher environments, again with approval gates.
For Azure DevOps, you can use variable groups to parameterize your pipeline. Also make sure to read through the custom parameters section on that link to parameterize parts of the template that are not parameterized by default.
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
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.
What are the different ways to deploy the adf v2 pipelines on different environment. What can be the best approach to do fast, repeatable, reliable deployments of pipelines.
Thanks in advance.
Currently in v2 there isn't really any best practices to follow as the development tools are still in private preview. But as somebody with access to the new dev UI and can offer assurances that the things you seek are coming. Probably later this month, but I'm guessing.
With regards to repeatability and automation of your deployments, you have 2 options:
Script the deployments using PowerShell. This works like the deployment of the data factory v1, but you'll have to use the v2 commandlets, and you'll have to add triggers. You can use PowerShell to parametrize connections to linked services and other environment specific values.
Deploy using ARM templates and run it from a PowerShell / TFS deployment. You can find an example here. In this case it is possible to use ARM template parameters to parameterize connections to linked services and other environment specific values.