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.
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'm trying to build my console application through Azure DevOps. So to this I'm following this tutorial.
The follow images, are from what I already did.
Build Solution Pipeline
Build Solution Pipeline / Publish
Build Solution Pipeline / Artifact
Deploy WebJob Pipeline
Deploy WebJob Pipeline / Variables
When I run the Build Solution the zip seems to work, because I see it.
But when I run the Deploy WebJob Pipeline I get ##[error]D:\a\1\s\***.zip not found.. I tried wwwroot/App_Data/jobs/, but still the same error.
What could I be doing wrong? What's the right way to set the zippedArtifactPath?
You're following the tutorial incorrectly. The tutorial is telling you to create a release. You're using a build pipeline to try to release. Although you can do that, you shouldn't.
You have two options:
If you want to keep using the visual designer, use a release. Look at the "Release" tab for this. Releases can be tied to build artifacts and will handle downloading the build artifact automatically.
If you want to use YAML, refer to the YAML documentation and set up a multi-stage pipeline to release.
What could I be doing wrong?
Check your error messgae ##[error]D:\a\1\s\***.zip not found we can find in the second build pipeline, the PS tried to get the xx.zip in xxx\s folder while in first build pipeline you published the xx.zip to xxx\a folder.
The $(System.DefaultWorkingDirectory) for build pipeline is xx\s folder while that for release pipeline is xx\a folder. In first build pipeline we published the xx.zip to Build.ArtifactStagingDirectory which is a xx\a folder, so we can't access the xx.zip from xx\s folder in second build pipeline's PS script.
What's the right way to set the zippedArtifactPath?
It's not recommended to build and deploy one web app using two build pipelines. For normal logic, we should do this by using combination like build+release pipeline just like the Toturial and Daniel suggests above.
We can use this variable $(Release.PrimaryArtifactSourceAlias) to get the artifact directory.
In your powerShell script you can set path variable like:
$path = "$(System.DefaultWorkingDirectory)\$(Release.PrimaryArtifactSourceAlias)\webjobs_drop\[ZIP_File_Name].zip"
[your build artifact name]\webjobs_drop[your zipped files].zip
"your build artifact name" - you should get it from your release pipelines Artifacts stage from where you are selecting your build artifacts
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'm attempting to deploy a web site to Azure using VSTS. Basically, I commit code to the GIT repo and have it setup to run CI, so it begins building as soon as I commit. However, once it hits the release section, it never copies the code to the Azure web app, rather, it gives me this line:
Info: Updating file ({projectname}\error.txt).
It doesn't copy the files I changed, but rather always just copies this file. I checked and there is indeed an error.txt file in my website directory in Azure, but it is always blank.
This build/deploy process isn't "standard" because the build step only downloads from source code, it doesn't build, because the website isn't a "web application", but rather just a "web site", meaning it doesn't need to be built.
So my build step is as follows:
Get Sources
Run on Agent - this step is empty
so the idea is that it just downloads everything from source control, that's it.
Then, my release step is as follows:
Artefacts are from build step above
deploy to environment 1 (dev)
Azure app service deploy, using "package or folder" as $(System.DefaultWorkingDirectory)/
Any idea what I might be doing wrong here?
So I actually figured this out and will leave this here in case anyone else needs it.
I admit I'm pretty new to the Azure/VSTS world, so maybe someone else is making my mistake as well.
If you don't need to "build" your project, then don't. I resolved it by simply skipping the build step altogether. What I was really after was to just download the files from source control and deploy them as-is.
In your release editor, you can specify which "artifact" you want to use to release, and one of the options is source control, which is what I did.
This would be useful for websites like mine where you don't need to build them (mine is DNN/DotNetNuke, so you don't build it before deploying).
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.