Azure DevOps multiple releases from single Artifact

Azure DevOps, how I could work earlier without you.

Azure DevOps isn’t new a Microsoft product, but I can’t imagine working without it now. Provides full software version control, creation of reports, tasks, etc. in the Board. Requirements management, project management, creation of automatic compilations or building tests and release management. In this article, I would like to describe the multiple-stage process of release.

In standard projects, the team has at its disposal two, sometimes three and even more separated environments, for example, Dev is used by the development team, the test is using for testing, finding bugs etc. And the final stage is Production, which is an endpoint for the end customer, users.

It happens that at the beginning of the project we build three separate integration processes for individual branches/tags from our repository. The same principle will apply to the release process. At this moment we start to make a slight mess in our project, and if it is not a small project then in the stream we suddenly see 50–60 builds and the same number of the release.
So how to reduce it about 60%? How to better control over the entire process? I invite you to the following article in which I will explain step by step how to deal with such a situation.

But, before I show you step by step how to build multiple releases, need to explain a few important words from DevOps methodology.

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

Donovan Brown

And the second concept which is very important.

A release is a collection of artifacts in your DevOps CI/CD processes. An artifact is a deployable component of your application.

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops

So now I would like to show you step by step a solution that helps you to have more control over the release process. Will keep order in the release gallery, and will cause more control of us released versions.

So our main target is to use only a single “Artifact” in the release process to deploy to multiple stages “Dev / Test / Production” but maintaining the division into divided into branches “dev/test/master” so that the integration process is implemented into to the appropriate stage.

Important!
If you want to have a fully automatic release process, without additional launching “Create release” in our pipeline, go to the Continuous deployment trigger in our artifacts and switch scroll to enable the service to automatically enable the release whenever new “build” is read.

When we already have the whole pipeline, we need to must configure the pre-deployment conditions like triggers, artifact filters, or pre-deployment approvals.

So in the beginning, we choose one of our Stage for example “Dev”

We’re getting a page to set all “Pre-deployment conditions”

Expand the trigger and choose one of the available options. In our case, we select “After release” and enable “Artifact filters”.

Press the “Add” button and add the available artifact.

In windows, we select type “Include” and build branch select “Dev”

Repeat all of the above actions so that each stage has an Artifact assigned with the dedicate branch for example :

• Dev –> Branch : Dev
• Test –> Branch : Test
• Production –> Branch : Master

After repeating all the above-mentioned activities, we should have such a view of our application release process.

Now we can return to our Repository, introduce some change in one of our branches by the commit and observe the whole process Continuous Integration + Continuous Deployment.

Build process in progress.

After done our build, we can look in progress release and check how status is ongoing.

As you can see in the above, I introduced a small change in my code and I commit it to the test branch and the entire release process was pushed only to the appropriate stage “Test”.

The process was successful, we can go to the Logs and see exactly what was done in the publishing process.

Now we have the whole, multi-stage process of application delivery, called CI / CD :)