I have a React app and I've set up a build pipeline that publishes the build directory as artifacts.
I was anticipating setting up a release pipeline to deploy it like I would with AzureFunctions or an AppService.
But apparently not: when I created the static website it has created a new build pipeline which also deploys. Why would you want every build to deploy? This is nonsense.
Also, the branch name is hard-coded somehow and can't be changed. Obviously I'll want to change that to master after I've got it working.
Furthermore, when trying to create a release pipeline there is no task for Azure static website.
What is going on?
Can I have a normal build and release like everything else?
Why does this have to be different -- the inconsistency is confusing and infuriating.
But apparently not: when I created the static website it has created a
new build pipeline which also deploys. Why would you want every build
to deploy? This is nonsense.
You can change the trigger of the pipeline to make the deployment be done as you want.
Check these official documents:
CI Trigger for DevOps
PR Trigger for DevOps
If you don't want the pipeline trigger automatically, you can replace the trigger part of the pipeline as this:
trigger: none
Also, the branch name is hard-coded somehow and can't be changed.
Obviously I'll want to change that to master after I've got it
working.
Just like the above, the design of Azure SWA in this regard is a bit counter-intuitive, these settings are also not operated on the Azure Portal side, but on the DevOps side.
You need follow these to change the source:
After the above two steps, the source of the Azure SWA will be changed successfully, but the UI of the Azure Portal side will not change immediately at this time. A success deployment will change it:
Related
What I'm thinking about is to have a step in the pipeline to generate a full-blown pipeline to run afterwards.
Apparently this particular thing is not there yet (feature requests here, here). But maybe somebody has some fresh thoughts on workarounds?
Not really. It's a pain that's just a fact of life when working with YAML pipelines. It's especially annoying when trying to work through runtime vs compile time variable resolution issues.
Commit, run, commit, run, commit, run, over and over.
For the dynamic work you could set up a repo with one dummy yaml file and a pipeline registration that targets this yaml file.
From a static pipeline that is responsible for kicking off a dynamic pipeline you then execute two steps:
Create a fresh branch of that "dynamic" yaml file and commit the required dynamic workload
Not sure about branch limits though. You could also decide to reuse a branch.
Kick off this "dynamic" pipeline through az devops cli using the static pipeline's access token
Also see the following documentation:
https://learn.microsoft.com/en-us/azure/devops/cli/azure-devops-cli-in-yaml?view=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
We often want to test the first part of our release pipeline using a code from the branch. While I can easily trigger the build from any branch, not so with the release pipeline - I have no idea how to trigger it from anything else other than the branch specified in it.
So far my solution was to temporary clone the pipeline, redirect to another branch and use it while testing. Then delete it.
But I wonder if there is a better way. We use TFS 2018 (on-premises), so no YAML to show here.
This is how our pipeline looks like:
When I click the Source I get:
And the Continuous Deployment Trigger on the Source:
Now clicking the Build Artifact:
And the CD trigger:
The four smoketest5x are the same. They have two tasks (a ps1 script and to publish the test results) and their triggers are:
Pre-Deployment:
Post-Deployment:
Finally, the Production stage. Its pre-deployment trigger is the most interesting:
And there is manual approval.
It does not seem possible to provide the branch at release creation time, but maybe I am missing something here?
You can't specify a branch at release time. If you need to do that, create a build pipeline that publishes an artifact, then release a build. You can choose builds versions at deployment time.
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.