I am using Visual Studio Team Services for my Builds and Releases. I followed Microsoft's documentation here to set up my release definition to deploy every time a linked build is created (Continuous Deployment). However the trigger is not working.
My build definition simply follows the steps bellow:
NuGet Installer
Visual Studio Build
Copy and Publish Build Artifacts
My release definition's trigger is set up as Continuous Deployment and pointing to my release definition. The environment is set up with "Automated: after release creation"
My build completes successfully but the release is never triggered. I can kick of the release manually and it works fine. I would like the release to launch immediately from the build. Any ideas why this is not working?
Here are the steps I would take to troubleshoot your problem:
Double click on one of your successful builds and download the log file. At the bottom of the log file you will see where your build was published. Does it show that you have your artifacts in your build? Is there anything highlighted in yellow?
Do you have your release definition linked to your build?
Is the path to your web deployment package associated with your build?
When I was first setting things up, I had the same problem and this is what I did to fix it:
On the build solutions section of your build , be sure that your MS Build is set to: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
On your CopyFiles section be sure you have your contents going to a zip folder:
***zip
On your release definition, be sure your Web Deploy package is pointing at that zip file: $(System.DefaultWorkingDirectory)***.zip
There wound up being a Db entry problem with our VSTS account. This was fixed by the rm_customer_queries_at_microsoft_dot_com team.
Related
I am trying to create a release pipeline in Azure DevOps. We already have a functioning build pipeline that works well, it is able to package the build with VSBuild and publish it as an artifact. Then in the release pipeline I am using an IIS Deployment job (which includes IIS Manage and IIS Deploy tasks) and it gets that artifact to deploy.
The problem is that we already have a publish profile (.pubxml) that should take care of pretty much everything the IIS Deployment is doing (at least as far I as I understand it). So to me it seems I have two options that don't require me to refactor the project configuration itself.
I can try to mimic the settings on the IIS Deployment job to match our .pubxml as closely as possible and manually applying any changes that aren't doable through the task settings. Obviously this is not ideal as that would require us to update both when ever we make changes and it introduces a large chance of the pipeline breaking down over time.
I can scrap the idea of using IIS Deployment and just use a VSBuild task that uses arguments /p:DeployOnBuild=true /p:PublishProfile=Staging. This doesn't seem like best practices because it means my release pipeline isn't passing a build package to deploy, it is just creating a new one at each stage.
So is there a better option that would allow me to utilize the package I created with VSBuild and the .pubxml configuration together in a deploy? If that isn't possible then are either of my options the "correct" way to handle my situation or am I just missing another method of deployment I could use?
Thank you for any help or insight you can provide. Please let me know if there is any more information I can give that would be useful.
You can try using publish settings file (*.publishsettings) for your IIS deployment.
A publish settings file (.publishsettings) is different than a publishing profile (.pubxml) created in Visual Studio. A publish settings file is created by IIS or Azure App Service, or it can be manually created, and then it can be imported into Visual Studio.
To view more details, you can see:
Publish an application to IIS by importing publish settings in Visual Studio
Deploy your app to a folder, IIS, Azure, or another destination
So unfortunately there doesn't seem to be a way I can achieve everything I wanted in this. The publish profiles are required for when we build the project so without making changes to how we configure those I need to build the project whenever I want to deploy. Ultimately I went with option #2. I essentially just copied most of the build tasks used in the testing pipeline and placed those in the release pipeline with a few modified commands to actually deploy the build once finished. It all seems to work just fine but still doesn't feel like best practices. If I am missing something please let me know and I will make updates as appropriate.
I setting up a build in Azure devops.
My project is mvc application.
Visual studio 2019
Everything build fines except that I do not want to build one of my projects(It has some issues. I do not want to remove it so i checked it to not be built) and in the configuration Manger the Build check mark is not checked . But the devops keeps building it and it breaks my build. No issue in visual studio 2019. Not sure what to do . Here is my yml file
Any help will be much appreciate it
But the devops keeps building it and it breaks my build.
For this issue, please check the following two points:
1.Whether the changes are committed and pushed to remote azure repo.
2.Since you're build with release+any cpu mode in CI pipeline, you must make sure you unchecked the Build box for Release+Any CPU page instead of Debug+Any CPU page.
In addition, Lance Li gave a detailed analysis about this issue in this case, you can refer to it for details.
I think in some of these project someone might have manully changed the project file or solution file.Beacuse using the configuration manager was not fixing the issue .So We had to remove all the project and set them up again
I am trying an automated build process in Azure DevOps for Salesforce. whenever a change is pushed to the repository, my build is triggered and it is working fine and pushing the changes to the related sandbox. Here is the proof for the same
Success Build Process.
The configuration of the build is Build configuration.
The build is working fine as expected. I now want to create a release which will push this change to a different environment, and I don't want this to be automated, hence the option of creating the release. The build path to the ant file in my release is exactly as it should be but I am getting this error. Release Error.
The release configuration is Release configuration
My Repository folder structure is: Folder structure. and my build.xml is within the deploy folder.
I don't know what I am doing wrong but the release is always failing and giving me the error which says:
Error: Not found antBuildFile: D:\a\r1\a\deploy\build.xml
Not found antBuildFile: D:\a\r1\a\deploy\build.xml
Based on the first image (Success Build Process), seems that you already have deployed your changes on that sandbox. Working with metadata deployment in Salesforce is different from java and .net, keep in mind that you already have the "executables", all those XML are already the code that you will change on the environment.
The second point is that on release you are in another agent, Buil and Release pipelines runs have their own lifecycle, so the code existing at the Build pipeline is not available until you send it on "drop" artifact, see Publish Build Artifacts task documentation. So that use copy task to put build.xml on publish folder, then you'll be able to use it on Release pipeline.
When you are executing ant go the /deploy folder and execute your command or check for your ant version using ant -version command.
I have successfully created a Build definition in VSTS for some SharePoint client side projects that I'm working on. I tried creating a Release definition but I can't seem to find any way for me to copy/download the artifacts created from my build definition locally. I may be missing something since I'm still quite new with VSTS but I can't seem to figure it out.
To downbload build artifacts from release when build successful, you can specify the release definition as below:
Add the build artifacts with latest version in release definition.
Enable Continuous deployment trigger for the artifacts.
Select the private agent which you want to download on the local machine.
Now when a build succeed, a new release will be triggered to download the latest build artifacts.
I have two build definitions in Visual Studio team Services.
I also have two release definitions in Visual Studio Team Services.
I want the release to be automatically triggered according to which build completes, but on the release definition.
When I go to the triggers tab, on the release definition, and select the continuous deployment option, it only gives me one artifact source label, for both builds.
How do I get my builds to produce different names artifact sources, so the releases can be triggered according to which build is run?
OK, easy answer found
On the release definition, click on "Artifacts", then link to the second build definition, and then you can trigger the release from the second build.