I've been fighting with this for a while. I've been able to get it working with two separate release pipelines, but not with one. It seems that in one pipeline the PR trigger for releases fires for all environments, even with separate build artifacts.
Goal is to have the following in one release pipeline:
PR to dev and merge to dev deploys to dev environment
PR to main deploys to QA environment
Merge to main of said PR releases to prod (with manual approval step).
It would be great to get this one one release pipeline, as that would reduce overhead and management, etc.
I've tried all sorts of variations with artifact release triggers and the environment pre-deployment conditions, but to no avail.
I've even tried using 2 separate build pipelines (one for main, one for develop) and then loading both as artifacts and trying to separate that way, but even when only 1 build pipeline runs, it triggers the PR release condition for both environments.
You should be able to achieve this if you implement your release pipeline with the new YAML pipelines.
The simplest option (which is not quite what you are asking for but should get the same outcome) would be to create a template with your core deployment logic, then create separate pipelines that reuse this template. That should allow you to replicate the triggers that you already had working for two release pipelines without needing to duplicate the deployment code.
Alternatively, you could set up a single YAML pipeline with Stages for Dev, QA and Prod, and set conditions on the stages, based on the source branch and/or build reason.
Related
I'm facing the following issue: I have one git repo with a Node.js application. The application is divided into several components, namely: server, client, microserviceA, microserviceB. There is also a directory named shared with some sharaed code used by all the other components.
I have a pipeline for each of the components that only runs tests, which run on pull-request to master. Each pipeline only runs when the PR contains changes relevant to him, e.g. server-ci will run only when there were changes in the server component, etc.
Now, on merge to master, I would like to build the components and deploy them on a staging server. Currently what I have is as follows: for each component (beside the shared) I have another build pipeline (<component>-build) which on merge to master builds the corresponding component (depending on the changes made, as above). I have one Release pipeline which takes as artifacts all these build pipelines and deploys them on the staging server. So the good thing about this is that merge to master which includes only changes in client will build only client and not all the rest of the components.
The problem is, that on merge to master that contains changes to several components, I'll have more than one build pipeline running, so they will both trigger the Release pipeline. This is not desirable.
A possible solution I thought about was, to have only one build pipeline which runs on merge to master, but then I'd have to build ALL the components on each merge, which is inefficient.
What is the best way to deal with such situation?
In the release stage settings you can configure that Number of parallel deployments will be 1:
I'd like to set up a pre-deployment gate with the following logic
If the branch (embedded in the artifact names, i.e. 1.2.4-myBranch)
matches the currently deployed branch (to the stage in question) allow the release to deploy automatically
If it doesn't match, require a manual override before the release is
deployed
The reason for this is we have multiple test environments where generally we only want to allow a release from the same branch to overwrite the deployment but obviously once we're done with a particular phase of testing we'd want to change the deployed branch.
I can't see any obvious way to do this, is it possible?
As a workaround:
We could create two Stages A and B
Select the stage A and configure the pre-deployment as below:
And configure stage B trigger mode to Manual only
Result:
If the branch match master, it will allow the release stage A to deploy automatically.
If not, we need to manually deploy stage B
You could also add your request for this feature on our UserVoice site, which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
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
I have dozens of similar apps with identical release processes.
Each app (in its own repo) will have its own Azure Pipeline.
I'm fine with a custom solution to this problem.
Options
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.
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]
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?
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]
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?
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...
I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.
Here's what I'd like:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.
The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.
I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).
Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?
I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.
Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.
I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage
The stages can then have approvals on them as well.
We are trying to set up an Azure DevOps Pipeline (fka VSTS Release Definition) to accomplish the following flow:
The Production stage (environment) will be triggered if the artifact's build includes a special tag named "Production". This is easily done by adding a artifact filter like so:
The Dev/Test stages (environments) will be triggered if the artifact's build does NOT include the "Production" tag. We are unable to accomplish this since the Exclude filter doesn't allow excluding tags.
The reason we want to skip Dev/Test stages when it's time for us to deploy to Production is because there might be a long time gap between when a build has been validated in Dev/Test and when it's actually Production deployment time. We tag our good build with the "Production" tag and we allow our development to keep going in the master branch. Therefore, when it's time for Production deployment, we don't necessarily want to re-deploy that build to Dev/Test again since Dev/Test might be already several versions ahead.
We know we could also create a Release branch from master to accomplish this goal. However, we'd rather not create Release branches if we could skip Dev/Test deployments using build tags instead.
Please advise. Thanks!
You may be able to achieve the outcome you are looking for but in a different way.
When you create a new release for your pipeline you can change automated triggers to manual triggers.
If you want to skip non production environments so an old version isn't deployed to them, change the automated trigger to manual for those environments.