We have an Azure DevOps Pipeline defined as a template in a .yml file, and would like to use this to build 100+ projects.
There is zero parameterization to do, and the template essentially just runs against the project repo as-is.
Normally, we would just go into each of those project repos and create an azure-pipelines.yml file and reference the template pipeline, easy.
However, I would like to know if we can avoid creating these azure-pipelines.yml in each of the 100+ project repos. Is there some way to just run the template against 100+ repos, but as separate pipelines?
No.
YAML pipelines are based upon the YAML being stored in the application's repo, as code, alongside the application code. You can pull in templates from other repos, but you can't have one pipeline that is automatically valid for any repo.
Trying to use one template to build 100+ applications without the possibility of pinning the template to a specific version on an application by application basis is setting yourself up for a nightmare at some point in the future, when the template changes in such a way that it's no longer valid for a subset of your 100 applications.
Related
I have two projects lets say A and B under one repository in azure Dev-ops. Each project has its own solution file.
The pipeline have tasks to build the solution and then upload the packages to the feed.
I want to select the solution file for project A if changes in pull requests are targeted for project A.
As of now i have created in a variable with default value and allowing user to override the variable name while triggering pipeline manually. PFB
But how to achieve same behavior to auto trigger the pipelines from
Pull Request. Is there any way to supply solution(.sln) name to
pipeline from pull request?
There is no way to implement that scenario within a single pipeline. Use two pipelines. Use different path filters to ensure the pipeline only triggers when appropriate paths change.
Anybody know if it is possible to pass in a repo name / base the build on a dynamic repo name? This would allow us to share the same build definition across different branches, cutting down on definitions when creating a feature branch, etc.
When using a TFVC repo we would store the different releases in the same repo but different paths. We could reuse the same build definition across different releases/FB's by altering the source path such as $/product/$(release)/......
It appears Git likes to have the repo hard-coded into the build (hence the dropdown - no way to plug in a variable.
While the question is targeted to On-prem Azure DevOps, if it is possible in the hosted environment it would be helpful to know.
I recommend using YAML build templates. By default these check out "self" and are stored in the repo. That way they work on forks, branches etc. Each branch can contain tweaks to the build process as well.
With the 'old' UI based builds this isn't possible.
What you are looking for is actually two things:
templates - this allows you reuse definition accross different pipelines
triggers - this allows you to trigger pipeline when commit happens on different branches
Looks like Task Groups solved the need (mostly). I was hoping to have one build definition that could be shared across multiple branches; while this appears to be possible on the hosted model, on prem is different.
I am able to clone a build (or use templates) to have an entry point into the repo/branch to get the sources, then pass off the work to a common task group. If I need to modify the build process for multiple branches, just modify the task group.
I created a new pipeline in Azure DevOps, and created a new branch for it.
As a result, DevOps automatically committed the YAML file for the new pipeline to my 'development' branch.
None of the other pipelines I've created have YAML files committed into the repo...
Why does it do this?
Do we have to keep the YAML file there?
It has nothing to do with the source code of the application, so doesn't seem to make sense why its stored there.
YAML is code for how your application is deployed, thus it is part of the source code. By putting it under source control it can keep track of version changes and any additional changes to parameters or variables that are determined or inserted in the build process.
This is opposed to the older ways of doing things where it was updated via UI and not source control and did not have peer reviews, branching merging, and additional polices that can be applied.
This on top of the the YAML Pipelines for Releases going GA the other week will make YAML under a repo even more powerful as the YAMLs will not only build but also release code.
In Azure Devops Service we define pipelines using the YAML syntax or through the user interface (Classic). So there're two kinds of pipelines, Yaml pipelines and Classic UI(Classic build and release) pipelines.
None of the other pipelines I've created have YAML files committed
into the repo...
Why does it do this?
It's expected behavior when defining pipelines using Yaml syntax: The pipeline is versioned with your code. It follows the same branching structure.
And one advantage for this is: A change to the build process might cause a break or result in an unexpected outcome. Because the change is in version control with the rest of your codebase, you can more easily identify the issue.
To sum up, the yaml pipeline will be added into version control and it's by-design behavior. If you don't want this behavior, you can feel free to use Classic Build and Classic Release pipelines. It's also a good choice! About the differences between these formats you can check Feature availability. Hope it helps :)
I would like to know if there is a mechanisim in Azure DevOps to reuse a definition for Azure DevOps Pipelines.
In my scenario I defined two Azure DevOps (Build) Pipelines to generate the artifacts of my web app; one for staging the other for production. The build definiton is the same in both cases except for two things:
a variable that set the build configuration for the ASP .NET Core (Staging or Release)
the branch that triggers the build (staging or master)
My goal is to avoid duplicated build definition that should be updated in both whenever somehting is updated in the project.
The build definition are in classic mode (no YAML files).
With classic you can create task groups and reuse those. You can select existing build steps and convert them to a task group and then reuse the task group across builds.
This is covered in the following document.
With yaml files you can use templates.
In my solution, I have two projects (a Asp.net MVC and a Windows Service). I want to create CI/CD pipeline to deploy web application and windows service on different VMs. But to achieve this my CI pipeline should be able to publish artifacts separately for both project and then I can feed these artifacts in CD pipeline for deployment. How artifacts for all projects can be published separately in a CI pipeline ?
PS: If I create two solutions each with one project only and create CI/CD pipeline separately, all works fine. But I want to achieve it with solution having multiple project as mentioned above.
You can use multiple, Publish tasks to create multiple artifacts in a single build definition.
For example lets say, you have below, as your current artifacts for a single project, comprising of _PublishedWebsites\MVS5WebApp (XCopy deployable website) and _PublishedWebsites\MVS5WebApp_Package (web deploy package).
If you want to separate these two, into two artifacts, you can use two Publish Artifact tasks as shown below, each one specifying exact path to publish (this path does not support wildcards, you just have to specify the folder you need to publish)
This will give you output as shown below.
In this example I just only used the Publish Artifacts task and created two artifacts using a single web site project. You can do same for your two project scenario. If you want to use wild card to filter more files before publish you can use "Copy File" task multiple times as required.
If you are using '.net core' task in the build pipeline then uncheck the checkbox 'Publish web projects' just after the command textbox.
Then it automatically creates publish artifacts separate for each project in the solution with the same name as each of the project files.
You have multiple ways to achieve that.
You can either create multiple build definitions targeting the project and not the solution in the build step with the proper arguments.
Or you can have one build definition with multiple build steps.
After that on the release side of things you can either leverage one release definition with multiple steps or multiple release definitions.