Today, as I promised in the last post, I’ll show you how to set Continuous Delivery on Visual Studio Online for your project.
Assumption
Similarly as on CI tutorial I just want you to have and existing Web project on some repository, plus this time it would be nice if you have build environment configured – we’ll be using the one set before.
Let’s hit this!
We’ll start with Build&Release toolbar and add new Release definition:
We want new Azure App Service Deployment… 
And here we have to remember to pick Continuous Deployment in the usual build. Project and source should be filled automatically, but even if not you won’t have any problem with selecting these 🙂
Click Create and Build Definition screen will show up. Few things to set here: choose your azure subscription (if you don’t have one, claim one-month trial as I did) and choose your AppService name. As you can see I also like to turn on ‘Remove additional files at destination’ in such systems, but it is up to you what you’ll have here.
Finally, when you save your release definition, you can make sure you have correctly set the trigger for running this build:
And… that’s it yeah? It should. Well, it terms of configuring release behavior we’re really done but… it’s time to do some tuning for our build configuration we created last time. In current shape, it won’t work, because it lacks some crucial details. We can confirm that by queueing new build – at least we would know that triggering is working properly, but surely our target site won’t be updated. So, what do we need?
Build definition changes
Separate build step for compiling Web application
Web application compilation output needs to be created in a slightly more extended way than building a usual C# project. We not only need bin folder with dlls there, but every script, font, view, style etc. Such output looks like below:
We can achieve this by setting separate build step for our Web Application so such output will be generated. Just add new build step for Web csproj, place it after Solution build and remember about these MSBuild arguments:
/t:PipelinePreDeployCopyAllFilesToOneFolder /p:Configuration=Release;_PackageTempDir=$(TempPublish);AutoParameterizationWebConfigConnectionStrings=false
and that would be it. Remember about adding defined variable – as you can see I use $(TempPublish) there, so you must have it in place as well. Go to ‘Variables’ toolbar to define your own one:
Zipping the output
You probably remember our release definition expects zip package to install new website shape, so we must create such file to make this happen. Our target files are stored in /home/tempPub folder and we want to zip this content into it. This would be our ‘drop’, which will become our build artifact, therefore add ‘Archive files’ step into build configuration:
It is important to uncheck ‘Prefix root folder name to archive paths’. We want only pure content – grabbing it in root folder additionally will corrupt server file tree and the Website won’t work.
‘Publish artifacts’ step is left as is was before. We have our zip in artifact staging directory, so there’s nothing we need to update here.
And that’s it! You should have your configuration working now 🙂 I hope these steps were clear enough for you – if not, let me know in the comments, I’d be happy to dive into details for you in requested area.
Summary (+bonus 🙂 )
Now we have well-configured development process. Each time you push your changes into the repository that’s what will happen:
- Files are being pulled from repository
- Project builds
- Tests run
- If success: prepared package is being sent to release process
- New package is being installed on target and changes are deployed!
Since now you’ll just care about pushing your code in and the rest would be done for you – by the smart process you’ve just set. Isn’t it wonderful? 🙂
Promised bonus: if releasing after each code contribution is too often for you, you can specify commit tag(s) that needs to be in for triggering the release (i.e. [stable]). Go to your release definition edit page, open ‘Triggers’ toolbar and set tags for CD trigger:
So you effectively have release being triggered ‘on demand 🙂
Thanks for reading!
