Deploy many apps through ONE release process via Azure DevOps

0
votes

I need to deploy many similar apps to the same environments with Azure DevOps.

What are some ways to share and maintain the release process for these apps....
to avoid updating every app's Release process when it changes?

Background

  1. I have dozens of similar apps with identical release processes.
  2. Each app (in its own repo) will have its own Azure Pipeline.
  3. I'm fine with a custom solution to this problem.

Options

  1. Make a Release for every Pipeline -- not a fan!
    • CON: Azure seems to want a 1-to-1 relationship between Pipelines and Releases.
    • CON: I want to avoid many Releases at all costs, since changes would be nearly unmaintainable.

  2. Use custom stage templates -- doesn't work for what I need

    • CON: Releases do not share custom stage templates.

      Custom templates that you create are scoped to the project that you created them in. [Azure Documentation]

    • CON: Custom stage templates cannot be updated (as of this post).

      To update an stage template, delete the existing template in a release pipeline and then save the stage as a template with the same name. [Azure Documentation]

  3. Put the release process in the Pipeline .yml file -- seems possible, but....

    • PRO: The process would be stored in a shared "common" repo.
    • PRO: Each app will have a minimal Pipeline .yml file, setting some parameters before running the shared process.
    • CON: How would I track and manually deploy releases without the Release portal UI? Am I missing something?
  4. Trigger the same Release with artifacts from different apps -- not sure this will work....
    • PRO: One release process, easy to track and deploy as needed via the Release portal UI.
    • CON: How would I track releases for different apps? Would I name Releases with the app name?
    • CON: I don't see how to set it up, since a Release is tied to a primary Pipeline.

      At the time of linking an artifact source to a release pipeline.... [Azure Documentation]

    • CON: Though multiple artifact sources can be used, Releases need a default artifact Pipeline or source repo. Would I need to setup the artifact source programmatically?

      When you link multiple artifact sources to a release pipeline, one of them is designated as the primary artifact source. The primary artifact source is used to set a number of pre-defined variables. It can also be used in naming releases. [Azure Documentation]

  5. Use multiple artifact sources and artifact variables -- not sure this will work....

    When there are multiple artifact sources linked to a release pipeline, you can access information about each of these. [Azure Documentation]

Bottom Line

I was able to solve many of these problems in Octopus Deploy. However, I'm having significant trouble seeing how to move my DevOps process into Azure DevOps. How would you handle this situation?

1
azure-devopsazure-pipelinesazure-pipelines-release-pipelineoctopus-deploy
Any feedback on the downvote and request to close? I'm all ears. – AndrewRalon
have you given any thought to task groups? docs.microsoft.com/en-us/azure/devops/pipelines/library/… – Sourav Kundu

1 Answers

0
votes

There is no perfect solution to meet your requirements.

Generally deploy multiple apps to multiple environments, we recommend that Make a Release for every Pipeline. But just as you mentioned it has 1-to-1 relationship between build pipelines and Releases and it has many releases.

We can deploy multiple apps to multiple environments through ONE release with customized Template as you mentioned, we can also use the Task Groups to combine a set of tasks together, then reuse them in different stages. But we still need to update the definitions accordingly (change the Task Group version) once the specific task group is updated.

Another way is Clone Stage, you mentioned they are the same environments, so you can config one stage, then clone stages from the existing one, just name the stages with the specific App names accordingly. But you still need to change the settings accordingly, for example the Artifact filters (see Release triggers) to determine the condition to trigger the specific stage. But in this way it will download all the artifacts first when you add multiple artifact sources, this will take long time to get sources...

enter image description here