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.
Related
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.
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.
The current scenario is I want a Release Pipeline that has multiple artifacts (one function and several apis). Each one with a cd trigger except for the one to prod which is manual for right now.
In the pipeline is there a way to prevent a particular job from running if deployed pipeline is the same as the original?
For example, a change is made to one of the apis but the rest remain the same I would want the release to get created and deployed but only run the deployment job linked to that particular artifact.
The reason being is that for a deployment to production it would be nice to have all the artifacts I'm looking to deploy in one place and all I would have to do to deploy to prod would be hitting deploy and if the latest artifact is newer then the one deployed it gets deployed but if it is not that deployment would be skipped.
Right now each artifact is in a separate release pipeline and each gets deployed separately, which means we are keeping a separate document with a list of all the release pipelines that needing to be deployed for a specific set of changes.
Any direction would be appreciated, thanks in advance.
I think you can do that with multi-stages and triggers. You can follow these steps:
Create a release pipeline.
Add all your artifacts.
Create multiple stages. According to your requirement, you may need as many stages as your artifacts.
Set triggers for each stage. Click on the lightning icon to the left of the stage. In "Triggers", select "Afer release". Then enable the "Artifact filters". Choose the artifacts that correspond to this stage as the trigger. Here is an example:
Then your release pipeline will be look like this:
When an artifact changes, the corresponding stages will be triggered, and no other stages will run.
It doesn't work. If an artifact is changed it doesnt checked that the artifact is newer
I have four environments that I deploy to.
I also have four different code branches that we use to deploy code from.
We constantly switch the branches we use to deploy on these environments.
One time I want to build and deploy a daily branch on my test environment.
Later I want to build and deploy a enhancements branch on the same test environment.
Next I want to build and deploy the daily branch on my test2 environment.
I think you get the picture
We are currently using a manual process to pull from the branch we want deployed, then zip it up and push it to AWS code deploy.
Using Azure DevOps pipeline and release what is the easiest method to allow me to switch to use different branchs on different environments.
I currently have a successful setup in Azure DevOps that performs a gradle build, creates the artifact and then lets me push it over to AWS CodeDeploy on one of my environments. I just can't seem to figure out a way to eastily swtich the branch without creating tons of Azure pipelines and releases.
Thanks all!
Where you manually trigger a build pipeline by clicking Queue or Run Pipeline, A new windows shown as below will be prompted which allows you to switch the branches.
If you want to automatically deploy different branch to different environment. You can push the build artifacts over to AWS CodeDeploy in a release pipeline and set the branch filters. Please refer to below steps:
1, set branch filter in the build pipeline as shown in below screenshot which will build the selected branched. Check here for more information about triggers.
2, create a release pipline to push build artifacts over to AWS CodeDeploy.
And Set the Artifact filters which will only allow the artifacts built from the specified branch to be deployed to this tage.
You could use a queue time variable to specify the branch name you would like to use on your build pipeline. You would need to:
Edit your build pipeline and create the variable on the "variables" tab. Make sure to mark the "Settable at queue time" check
variable creation
Update the source of your build pipeline, to specify the new variable under the "Default branch" option. It would look something like this:
pipeline source
RUN your pipeline. Before finally clicking on RUN, you will be able to specify the desire branch:
set variable value
Hope this works
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.