Multiple Release Pipelines - azure-devops

Need your inputs as I am new to Azure DevOps. Is it possible to have multiple release pipeline & single build pipeline in Azure? As per the best practices, if within a single solution, there are multiple projects, it's best to have single build pipeline per project & then create corresponding release pipelines. Now information I have received from developers, their application is so integrated that it is very difficult to seperate out projects to their individual solutions. They are suggesting to create multiple release pipelines for windows services & web services for various projects.
is it still possible?

Is it possible to have multiple release pipeline & single build pipeline in Azure?
The answer is yes.
There is no one-to-one correspondence between the build pipeline and the release pipeline. We can have multiple release pipeline & single build pipeline, or have multiple build pipeline & single release pipeline. It all depends on your needs.
But when we are dealing with these special situations, we need to be very clear about the output of the build pipeline and the generation of artifacts or the input of the release pipeline and the deployment of artifacts, otherwise it is easy to cause confusion.
For your situation, I have create a simple sample to explain the process.
In the build pipeline, I have two projects in my build pipeline. Build the solution (or all projects) by Visual Studio build task, then we need create two artifacts for each projects:
Then publish the build artifacts with different artifact name:
So we get two artifact for one build pipeline:
Last but not least, we create multiple release pipeline (or we could create multiple stages) for windows services & web services. Release pipeline will download two artifacts from the build pipeline, We only need to deploy the artifacts of the corresponding project to the corresponding server instead of deploying all the artifacts to the server.
For example, if we only deploy the artifact from the project1, we just need to select the artifact, like:
The artifact source should be:
$(System.ArtifactsDirectory)\_TestBuild\drop1

Related

How To Group Azure DevOps Build Artifacts From Multiple Projects Into One Release Pipeline By Just Build Artifact Tag

All the project builds for release 3 have been tagged with relese3. Out of 100 projects I'm not sure which ones are release3. I need to group all the build artifacts from each project tagged with release3 into one release pipeline. Is there a way to add build artifacts to a release by just build artifact tag?
Don't know which projects are tagged release3:
Is there any way to group build artifacts from multiple projects into one release pipeline by just build artifact tag?
Or can one release pipeline just use the Azure Trigger Pipeline task to trigger all project release pipelines with a build tag of release3?
How To Group Azure DevOps Build Artifacts From Multiple Projects Into One Release Pipeline By Just Build Artifact Tag
I am afraid there is no such way to do this at this moment.
As we know, in the release pipeline, we need to specify the pipeline which need to be deployed.
We cannot leave the option source(build definition) blank (it is required). in addition,
If this function is supported, there will be a certain risk, because the release pipeline is directly related to production, and tags are used to bind all related build pipelines, which makes if our development engineers accidentally use the wrong tag, or in the wrong If the tag is added to the pipeline, the wrong build artifact will be released to the actual production environment because the pipeline is not clearly specified in the release pipeline. will cause losses.
If you feel this feature is important to you, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/report?space=21&entry=suggestion), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.

confusion on Azure DevOps pipelines

I've recently been working on switching from On premise TFS to Azure DevOps, and trying to learn more about the different pipelines and I think I may have had my Build pipeline do too much.
Currently I have my Build Pipeline do
Get Source code from Repo
Run database scripts/deploy dacpacs
Copy files over to virtual machines that have web application set up already
Run unit/integration tests
Publish the test results
I repeat these steps closely multiple times, one for develop branch, one for current and previous release branch.
But if I want to take advantage of the Releases and Deployments areas what would that really get me?
It looks like it would be easier to say yes this code did make it out to this dev/beta environment.
I'm working with ColdFusion code that includes some .NET webservices within the repo, would I have to make an artifact that zips up the repo and then deploys it, or is there a better way to take advantage of the release pipeline?
It's not necessary to make an artifact that zips up the repo and then deploys it. There are several types of tools you might use in your application lifecycle process to produce or store artifacts. For example, you might use version control systems such as Git or TFVC to store your artifacts. You can configure Azure Pipelines to deploy artifacts from multiple sources. Check the following link for more details:
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#sources

Is is possible to inherit a definition of Azure DevOps Pipeline?

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.

Azure pipelines. Repeat tasks without project rebuilding

I use azure pipeline for build my solution.
Aftere build I need to generate and upload multiple packages with different assets. Packing implemented as a number of additional tasks in my agent job.
But I need ability to generate only selected packages or all packages based on specified arguments.
What is the best way to achieve this?
Ideally, it would have 2 pipelines. The first is automatic project build. And the second should use the result of the first and be able to repeatedly start manually with the desired parameters to exclude project rebuild. But I do not know how this can be implemented.
Not sure if I understand the question correctly, but two possible answers would be:
Classic pipelines, with build pipeline for project build and release pipeline for uploading the artifact(s) that build generates, if using release pipeline is applicable. Release pipeline can have a cd-trigger for the first run, and redeployed manually after that. If need to change release variables for subsequent deployments, you can create a new release with the same build artifact.
Multi-staged pipeline, with build and upload as different stages, manually redeploy/rerun the upload stage when needed. Build phase generates deployable pipeline artifact(s).
Somehow I think you're looking for more elaborate solution, as you state that you're already using pipelines. So how about creative use of conditional tasks (https://learn.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml) using pre-defined variables like Build.Reason (with value 'Manual') to exclude the execution of certain tasks in some runs. Then group tasks you want to re-use into either build templates or task groups.

How to publish artifacts separately for each project in solution from VSTS CI pipeline?

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.