I'm having some trouble deploying an Azure Web Service using the new Team Build that is available at Visual Studio Online. When the solution have been built successfully, the deployment task tries to find the CsPkg and the CsCfg, which fails.
How do I specify the "Path of CsPkg/CsCfg under the default artifact directory" that is required? Do I have to specify some MSBuild arguments?
You can use the $(build.stagingDirectory) variable in the CsPkg/CsCfg fields. This will be the root of your repo. Your binaries will be at some location under there. E.g. $(build.stagingDirectory)\*.cspkg and
$(build.stagingDirectory)\*.cscfg
There's a huge list of built-in variables on MSDN.
You may also have to build your cloud service project with the MSBuild argument /t:Publish
I just checked: If you use the "Cloud Service" deployment template, all of this stuff is automatically filled in for you, including the paths.
Related
When I deploy my Azure Function project to my Function App based on the v2 runtime, the binding extensions my project depend on (Azure Storage in my case), are not automatically created.
I deploy my project with an extensions.csproj file on the root, but after deploying I have to manually run the following command to create a bin and obj folder at wwwroot.
dotnet build extensions.csproj -o bin --no-incremental --packages D:\home\.nuget
If I understand correctly, this should happen automatically.
For deployment by CLI func azure functionapp publish
Function core tools use zip deployment to deploy functions, in this way, kudu doesn't build project by default. To enable the feature, set SCM_DO_BUILD_DURING_DEPLOYMENT to true in Application settings on portal.
As for why the default setting is false, zip deployment usually requires the content to be deployed including all related files hence there's no need to build again.
For Azure function core tools, we usually use command func extensions install to register extensions for input/output binding when extensions are not installed automatically like we create trigger from template. This is why command func start and func azure functionapp publish doesn't build extensions.csproj, extensions are supposed to be installed before we run or publish functions.
Update for DevOps deployment
With Azure pipeline, we need to build extensions.csporj before archive files. Add a .NET Core build task, arguments are -o bin.
If you want kudu to build project, go to Deployment Center under Platform features. Choose VSTS as a CI repository and kudu will build and deploy project for you.
When using Visual Studio, you'll be referencing the extension packages directly from your project in order to use their attributes and other types, so Visual Studio handles the installation process, but registration still needs to be performed.
This is handled by a custom build task, added by the Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator NuGet package, which must be explicitly referenced (this will be automatically brought in by the SDK/Visual Studio tools in a future update).
These are the steps you must follow to use the CosmosDB extension mentioned in our previous example:
1.Add a reference to the Microsoft.Azure.WebJobs.Extensions.Storage NuGet package
2.Add a reference to the Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator
3.Build the project
For more details, you could refer to this article.
Is there a way of having my Azure WebJob automatically deploy without needing to right click and select "Publish as Azure WebJob" every time? i.e. when I check-in my solution it is automatically deploy to the Azure Portal webjob section
While I tried to accomplish this, I found out that there is no tooling support for dotnet core projects as of now. The proposed webjobs.props/ msbuild solutions are all dotnet framework specific.
However I also found out that a webjob can be anything that's executable on the local machine (could be node.js or just a batch command).
The key is to understand how WebJobs are recognized by the host:
A WebJob on a Windows host is (by what I gathered from experimenting with it) just a run.cmd file that contains instructions on how to start the webJob. For dotnet core that would be dotnet MyDll.dll %* (%* to pass arguments for output redirection etc. down from the host).
Now depending on wether the job is continuous or triggered the run.cmd file needs to be located either at app_data/jobs/continuous/[NameOfJob] or app_data/jobs/triggered/[NameOfJob]. For the triggered job you could also add a schedule using a settings.job file like described here.
If there is a run.cmd at the proper location it will be recognized as a WebJob
Now to deploy a webjob using VSTS regardless of the runtime framework follow these steps:
Build/Publish your WebJob if necessary to get the executables
Add a run.cmd file next to your webjob executables that contains the proper startup instructions. You could also add settings.job here if needed.
Create the folder hierarchy app_data/jobs/[triggered/continuous]/[nameOfJob] and copy your executables into the lowest folder. Make sure run.cmd is directly under the [nameOfJob]/ directory
Zip the app_data folder so that the zip-package contains the entire hierarchy
Publish your zip file using the normal Azure App Service Deployment task (just like deploying the web app)
And that's it.
Yes you can.
Brady Gaster has written about this on a blog post (haven't tried it myself).
From what I gather, the TL;DR; summary is the following:
add a file named webjobs.props to the properties folder of the Web Application Project or Console Application you’re publishing
After that, edit the file so the ManagementCertificate, SubscriptionId and PublishSettingsPath are filled with correct data.
Now you should be able to publish the files using the command
msbuild WebJobDemo.Web.csproj /p:DeployOnBuild=true /p:PublishProfile=WebJobDemo /p:VisualStudioVersion=12.0 /p:Password=asdfasdf
(Note, post is written for VS2013)
Afterwards you should see something like this.
You could of course automate this in VSTS (or any other build/deployment tool for that matter) whenever something is checked in to your repository.
A (rather complete) answer on how to do this in VSTS via the command-line can be found in this answer: https://stackoverflow.com/a/45703975/352640
You can do it through Continuous Integration Build (trigger the build once check in).
Regarding deploy WebJob, you can generate a package through Visual Studio Build task with /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)" argument.
Then deploy it through Azure App Deployment task.
More information: Deploying and Schedule Azure WebJobs from VSTS to Azure Web App
In Visual Studio in order to enable automatic WebJobs deployment together with a Web project right-click the Web project in Solution Explorer, and then click: Add > Existing Project as Azure WebJob and create your WebJob.
More details can be found in an article by MS - webjobs-dotnet-deploy-vs
After I follow this tutorial: http://docs.nuget.org/Consume/package-restore/team-build, I found 2 main issues or concerns:
When I am using Azure Cloud, my build process template will be Azure Continuous Deployment Template instead of using the Default Template, and this has a Solution to Build property instead of Projects so when you replace the .sln with build.proj, the build will generate an exception: "Exception Message: Please specify a Visual Studio Solution (.sln) to build. (type BuildFromSolutionException)"
Other issue that I maybe will face later is: how to specify my own nuget package sources? I may have additional sources beside https://www.nuget.org/api/v2/
Default Template
Azure Continuous Deployment Template
Currently our developers deploy our Mobile Service (.Net backend) from Visual Studio 2013 using the Publish Wizard. Occasionally this means that a developer deploys something that either wasn't committed at all or wan't pushed to the origin source control repository. We are already using Visual Studio Online Build servers to do Continuous Integration from the origin server so it would make sense to use the files it builds to do the deployment to remove this risk.
Currently the only way I can see of doing this is to do a "download drop as zip" from the Visual Studio Online build portal and then do a FTP style deployment. This means I lose the web deploy features of only uploading the changes.
I noticed there is a different build template called GitContinousDeploymentTemplate which allows you to specify a Windows Azure Deployment Environment, but this seems to only be applicable for traditional Cloud Services or Web sites.
If anyone knows a good way of doing this any help would be much appreciated.
Cheers
F
From here
Found a solution.
In the build definition's MSBuild arguments, add the following:
/p:DeployOnBuild=true /p:PublishProfile="{publish name}"
/p:AllowUntrustedCertificate=true /p:VisualStudioVersion=12.0
/p:UserName={username} /p:Password={pw}
You can obtain the value from the publishing profile that can be downloaded from the
Mobile Service dashboard on Azure managament portal.
Under Deployment, add the path to pubxml file in source control under "Path to Deployment Settings". Note: add an extra backslash at
the end of the path to escape the last "\".
One problem with this solution is that deployment happens regardless
of your tests outcome, but that could possibly be remedied by
modifying the build template. We used the
GitContinuousDeploymentTemplate template in our case.
Visual Studio 2013 has a publish wizard for Cloud Service projects that packages and deploys a cloud service based on settings persisted in a .azurePubxml file.
I'm setting up automation of this process on a CI server, and want to leverage this functionality within MSBuild, but I'm unsure if it's even possible.
I have found a lot of articles that talk about shelling out to a PowerShell script and using a custom MSBuild target file to do the deploy, but that seems like a duplication of information that I'd rather not delve into.
Given that I have the Azure subscription credentials installed on the build machine, VS 2013, and Azure SDK 2.2, can I invoke the same mechanism that VS 2013 uses in the publish wizard to package and deploy my cloud service?
Currently, using MSBuild with the publish target, I can package the service into a .cspkg file, but I cannot figure out how to trigger to package/deploy based on a profile (.azurePubxml file) that defines the VS build config, and all of the Azure settings.
So, as you pointed out, the default targets will only give you a package. From there, Visual Studio is publishing things using their own infrastructure. Publishing the build from a CI server is considered something external to actual build process and rather something that is part of the deployment process.
If your CI technology has support for PowerShell then it's as easy as automating the Windows Azure PowerShell cmdlets to do your bidding. There's a nicely detailed article on how you might do this with Team Builds in TFS here on MSDN.