I created a sample project using VS2017 "ASP.NET Core Web Application" with Angular.
Then in VSTS I built using Build Template: ASP.NET Core (Build ASP.NET Core Web Application targeting .NET Core). This built successfully and in the artifact section kept the build in a .zip file.
I would like to deploy it to a scale set. So for the Release section I used "Azure Virtual Machine Scale Set Deployment" template. While filling it out there is a field "Deployment Script field" which is mandatory. Not sure what this script is used for and how do i configure in it and where to source the script from.
TL;DR:
This script deploys the content of your deployment package on the virtual machine that you're preparing. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, the .NET Core Windows Server Hosting Bundle and copy your app to IIS.
Extra info
The Azure Virtual Machine Scale Set Deployment template creates an environment with two tasks:
Build immutable machine image
Azure VMSS: update with immutable machine image
Both tasks have a bunch of fields that need to be configured. Release Management allows you to link important fields to your process. This means that these settings are all grouped under the environment and can be easily set without going through the tasks.
If you look at the following screenshot you'll see that beneath the selected Deployment script field there is a line: This field is linked to 1 setting in 'Build immutable machine image'.
If you look at the documentation for the Build immutable machine image tasks you see the following for the Deployment script:
Deployment Script: Specify the relative path to the PowerShell script (for Windows) or shell script (for Linux) that deploys the package. This script should be within the deployment package path selected above. For example, Deploy/ubuntu/deployNodejsApp.sh. The script may need to install Curl, Node.js, NGINX, and PM2; copy the application; and then configure NGINX and PM2 to run the application.
So this is the script that will automatically deploy your application to a VM. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, install the NET Core Windows Server Hosting bundle and copy your app to IIS.
I would encourage you to first create an empty Windows Server 2016 VM and experiment with creating a script that prepares the VM and installs your app. Once that's done, you can reuse this script in the Build Image task in VSTS to automate VM and image creation and use that image for your Scale Set.
UPDATE
Your VSTS Build produces an artifact. In your scenario, you are already publishing the zip file with your web application. You can configure the Publish Build Artifacts task to also publish any deployment scripts you want to use during your release. These scripts should be stored in version control. The whole artifact, including your zip file and any deployment scripts you add, is used as input to your Release Definition. The zip file contains your web app as a Web Deploy package that you need to deploy to IIS. This piece of documentation explains how to install Web Deploy and use it to deploy your app.
Related
I have a web app, and I've setup VSTS to create a package in build, and then deploy it using release management.
It puts all of the result in the wwwroot of the site if I look at it in ftp so I get:
/site/wwwroot/
/wwroot
/
This doesn't run and I get a 404 error.
If I use the URL and go say /wwwroot/images/ it returns it just fine.
The app is set to use .net core and I'm doing a self-contained package.
How do I get VSTS release to put the files in the right place and what is the right place ? I can't find any documentation on this anywhere. Everything is to do with Windows.
Also, what linux target should the dotnet application be set to for self-contained? I have it using ubuntu but I'm sure that's wrong and it's something else.
Please use Azure App Service Deploy task with 4.* (preview) version instead, and deploy again:
I had a similar issue and I responded here. Essentially you need to have a startup command pointing to your DLL because Dev Ops deploys the package in a different way than VS.
Deploying .Net Core to Linux WebApps on Azure with DevOps
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
All the deployments in my work place are manual. I have been looking at ways to automate all of this using MSBUILD and MS Web Deploy. What I have managed to get working is as follows:
build/compile solutions
run database migrations
deploy directly to website using ms web deploy
All from one MSBUILD script.
This differs slightly from the manual process, as when a new version of a website is deployed manually, it is put into a new folder that is datetime stamped. And then IIS is pointed to the new folder.
My question is, how would I do these last 2 actions? i.e. write to a specific folder that sits a level higher up than the folder the current website points to, and then repoint to the new folder IIS.
Web Deploy does not support this functionality directly. Thankfully it does provide the runCommand provider, which is what you'll end up using.
%windir%\system32\inetsrv\appcmd.exe is the utility you'll use to swap site directories. An example of usage can be found here: How do I change the physical path of web site in IIS7 with APPCMD?
Create a script that calls appcmd. This script will always sit on your destination server. You can either decide to include it as a part of your site deployment, or move it along into the new directory from the old one. The "web deploy user" on the destination machine needs to have the appropriate credentials and access to create directories.
In your MSBUILD script, prior to deployment, call the script on the destination server. E.g.
msdeploy.exe -verb:sync -source:runcommand="C:\path\to\wwwroot\bin\script.bat"
-dest:auto,wmsvc=https://contoso.com:8172/msdeploy.axd,username=%username%,password=%password%
Then deploy as usual
NOTE:
Try to avoid this way of deploying entirely. If you're looking to snapshot your site, consider deploying to a package (zip), and then deploying that package to your destination server. Rollbacks should be handled by deploying an older package, not by repointing to an older directory.
Does anyone know of an automated way to deploy a web role to Azure with the "Enable Web Deploy" option enabled? We have an automated acceptance test process that deploys to Azure using Web Deploy to save time. But we would also like to automate the full deployment of the web role so that it could run off-hours on a less frequent basis.
We are currently using the WAPPSCmdlets module to automate full Azure deployments. However, neither this nor the newer official Azure Powershell cmdlets seem to expose a way to enable Web Deploy in new deployments.
What you'll need to do is create a startup task that does the following:
Download and install Web Deploy
Windows Azure Bootstrapper can help you to download and run the installer from a startup task.
Configure Web Deploy with PowerShell. You might want to start with this article: PowerShell scripts for automating Web Deploy setup
Running PowerShell from a startup task might seem tricky at first. If you run into trouble, take a look at this article: Azure Startup Tasks and Powershell: Lessons Learned
Keep in mind that this startup task should only run for CI deployments and not for your production deployments, so this might be something you need to take care of in your build process (you can use different Cloud projects in Visual Studio for example).
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.