I am working for a company that develops a lot of apps and we use Azure devops portal for all of our pipeline releases etc.
So, the general flow is that a developer will create a branch to do the development on and change the code on that branch. They would like to deploy that branch before it is merged back into the development line from a pipeline, rather than from visual studio, which they currently do. So, it's about giving the developer to the option to choose which branch to deploy from.
Has anyone done something similar or point me in the right direction to how I could go about this?
When creating the release, currently there is no build-in feature to choose which branch to deploy from, the release pipeline works with the corresponding source Artifacts configuration.
A good approach for your scenario is referring to the build id on your build pipeline (instead of release pipeline).
When running the build pipeline, you could choose the target branch and record the build id for this run.
In your release pipeline, you could check whether the source Artifacts is from your target branch by checking the build id.
Related
So I'm currently trying to proceed through the release pipeline portion of an Azure DevOps Fundamentals for beginners course on Udemy, and the goal is to deploy the code for a small webapp game called "Flatris" for the purpose of showing how Azure works.
I've been following along with all the steps as per the course, but when I run the release pipeline build, it consistently fails with the message:
"Error: No package found with specified pattern: D:\a\r1\a***.zipCheck if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
So far, I've double checked the function of the Web App resource provided through Azure, it's showing traffic when I try and run the pipelines, so it's not the problem(i think), I've double checked the repositories, and they seem to be functioning well(i think), I'm unsure about the artifacts and whether that may be the source of the problem, but theres not enough specificity in the error logs for me to accurately isolate where the problem is.
I don't know if anyone else has managed to get pat this problem, or if it's unique to me with something I'm doing, but any help would be greatly appreciated.
Error: No package found with specified pattern: D:\a\r1\a***.zip
Check if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
When we use release pipeline for our application, we have to specify the artifacts that make up the application. And the artifact is a deployable component of your application. It is typically produced through a Continuous Integration or a build pipeline. Azure Pipelines releases can deploy artifacts that are produced by a wide range of artifact sources such as Azure Pipelines build, Jenkins, or Team City.
According to the error message, it seems you are using the build pipeline as artifact resource in the release pipeline.
To resolve this issue, we need make sure we have use the Publish build artifacts task to publish the artifacts to the Azure Pipelines in the build pipeline.
Then select the above build pipeline when we select the artifact source type:
In this case, Azure release pipeline will download the artifact automatically when we execute the release pipeline, the artifact will be save in the default folder D:\a\r1\a. That will resolve your issue.
A release can be triggered when the build artifact is available as shown in screenshot below.
So does this necessitate that for the release pipeline (configured for build artifact) to get triggered, the build pipeline must have the "publish artifact" task?
Agree with Shayki Abramczyk, the answer is No. But I think maybe you need more descriptions to help you understand ~
In your situation, you set build pipeline as release pipeline's artifact. If you've checked this document you would find these statements:
1.When authoring a release pipeline, you link the appropriate artifact sources to your release pipeline. For example, you might link an Azure Pipelines build pipeline or a Jenkins project to your release pipeline.
2.Note from here:
You must include a Publish Artifacts task in your build pipeline. For XAML build pipelines, an artifact with the name drop is published implicitly.
3.Auto-trigger releases feature(CD trigger in artifact): New releases can be created automatically when new builds (including XAML builds) are produced. See Continuous Deployment for details. You do not need to configure anything within the build pipeline. See the notes above for differences between version of TFS.
To sum up, the artifact source here represents a build pipeline instead of the outputs of a build pipeline. So when you enabled the CD trigger in artifact(in your situation a build pipeline), the release is triggered whenever a new build finishes. And this behavior won't be affected by whether the build pipeline has Publish Artifact task to publish the outputs from it.
For the 2.Note: It can be considered as we must include a Publish Artifacts task in build pipeline so that the release pipeline can access the outputs of build pipeline. And then we can deploy the outputs(.dll/.exe or what) to target machines/environments. (Actually we think the must in document should be replaced with It's recommended to/should)
Publish Artifacts task make the build+release process meaningful. Cause if our release pipeline can't access outputs of build pipeline, what should we use to deploy? But whether this task exists or not won't actually affect the CD trigger. (Just like the third statement:You do not need to configure anything within the build pipeline)
The answer is No, the release will be triggered when the build finished even he doesn't have Publish Artifacts step.
I have a VSTS project and I'm setting up CI/CD at the moment. All fine, but I seem to have 2 options for the publishing step:
Option 1: it's a task as part of the CI Build, e.g. see build step 3 here:
https://medium.com/#flu.lund/setting-up-a-ci-pipeline-for-deploying-your-angular-application-to-azure-using-visual-studio-team-f686c8f190cf
Option 2: The build phase produces artifacts, and as part of a separate release phase these artifacts are published, see here:
https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-cd-part-1?view=vsts
Both options seem well supported in the MS documentation, is one of these options better than the other? Or is it a case of pros & cons for each and it depends on circumstances, etc?
Thanks!
You should definitely use "Option 2". Your build should not make changes in your environments whatsoever, that is strictly what a "release" is. That link you have under "Option 1" is the wrong way to do it, a build should be just that, compiling code and making artifacts, not actually deploying code.
When you mesh build/releases together, you make it very difficult to debug build issues. Since your code is always being released, you really have to disable the "deploy" step to get any idea of what was built before you deployed.
Also, the nice thing about creating an artifact is you have a deployable package, and if in the future you need to rollback to a previous working version, you have that ready to go. Using the "build only" strategy, you'd have to revert your code or make unnecessary backups to achieve this.
I think you'll find any new Microsoft documentation pointing you toward this approach, and VSTS is completely set up like this. Even the "Configure Continuous Delivery in Azure..." feature in Visual Studio 2017 will create a build and a release.
Almost all build tasks are the same as release tasks, so you can deploy the app after building the project in build process.
Also there are many differences between release and build, for example, many environments, deployment group phase in release.
So which way is better is per to your detail requirement, for example, if build > deploy > other process is simple, you can do it just in build.
Regarding Publish artifact task, it is used to publish the files to VSTS server or other place (e.g. shared folder), which can be used in release as Artifact (Click Add artifact > Build in release definition), you also can download them for troubleshooting, for example, if you are using Hosted Agent that you can’t access, but you want to get some files (e.g. build result), you can add publish artifact task to publish to VSTS server, then download them (Open build result > Artifacts)
I'm using Visual Studio Online, and looking at CI and automated deploys
My Web Test Project has three branches: DEV,UAT,LIVE
I have a build Definition that builds from the DEV branch and uses msbuild to deploy the Website to my UAT server, this works fine. What I would like to do is after the publish, branch the code from DEV to UAT
any help would be appreciated
You can use PowerShell post test to call "tf merge" to push code from DEV to UAT.
You are doing it the wrong way round. If you are promoting by quality that is a value of the build output and not the code.
A better way would be to not have branch by quality (dev->qa) but to have branch by release (1.0->2.0). Then have a single build on a version that progress through DEV->QA. This is the recommended method of controlling quality and minimises risk. The release management tools that are part of TFS and VSO use this method.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
If you want to increase and control quality you will need to move away from branch by quality. It is not possible to achieve continuous delivery of any form with it.
Let's say we have 2 branches: Development and Production
Also we have 2 servers on Azure in different affinity groups.
Is there a way to automate the process so that on person choosing version X that was 'accepted' in development merges code into production branch and publishes to production server ?
Ideally I would want to have a Changset# and set to production that will merge the production branch (with all the required previous changesets) and get published to server.
The chosen changeset does not have to be the latest on development.
Following 4 steps should do it for you:
1) Create a new build definition for Development branch using TfvcTemplate.12.xaml (only available in TFS 2013) as it has post-build script option (see image below).
2) Create a powershell script to merge the changes to branch using tf merge command. You will have to pass the changeset # to the script using Post-build script arguments.
See this URL: http://msdn.microsoft.com/en-us/library/bd6dxhfy
3) When you run the build set the Get Version(see image below) and it will take the changes from that version. After the build is successful it will merge the changes to the production branch using the step 2 above.
4) Create another build for the Production branch and use the link specified in the below answer to deploy the code to azure on check-in to the branch.
Can I automatically update a live site after each commit using TFVC and Azure?
You can also look at InRelease (link below) for Release Management and automation (not supported for Visual Studio Team Services yet)
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
Hope it helps.