< Part 1 you’ll need to read this first 😉
Setup continuous integration
Now for the second part, setting up ci and cd. Warm up that mouse because this requires a lot of clicking around in VSTS.
Connect VSTS to GitHub
The first thing we’re gonna do is to connect VSTS to GitHub. To do this go to settings > services:
Then add a new GitHub endpoint and click ‘Authorize’:
Now it’s time to setup the build. Just click ‘New build’ and select the empty template. For the Agent queue I choose the Hosted 2017. The first step in the build is to get the sources from GitHub. We connected that the step before and we’ll just have to select the repository.
After that, we’re gonna add the steps for restore, build and publish, so we’ll need 3 .NET Core Tasks.
First step choose ‘restore’ as the Command, set the Path to projects to */*.fsproj. All .NET Core steps need that.
Next the build step, pretty straight forward:
And now the next step publish, the part that cost me the most troubles. If you look at the Arguments, you’ll see the -r win10-x64 switch. That makes it a self contained deployment If you don’t do that, the combination .NET Core 2.0 + Suave will give the following error on the Azure Web App:
System.IO.FileNotFoundException: Could not load file or assembly ‘System.Runtime, Version=126.96.36.199
I tried a lot of things to get it to work, I ended up using this solution (part of my quest here)
We now add the last Task ‘Publish Build Artifact’, which will drop the package in the $(BuildArtifactStagingDirectory)
And now some of that VSTS magic, just flip the switch and set the trigger so that every commit will result in a new build.
All Done! Now create a new build to test if everything works. (Or commit a change of course!)
Last but not least, releasing the freshly build package. Create a new release definition and select the ‘Azure App Service Deployment’ template.
We need to select which artifact to build and we’ll choose the stuff we just created with the build. This is all just too easy.
Set the automatic deployment by clicking the trigger button and enable Continuous deployment.
Then we need to configure where we want to deploy to, do this by clicking the 1 phase, 1 task link.
Here you can select your Azure Subscription and the App service where you want to deploy. And that’s almost all folks.
I Added 2 extra steps to stop the app service before deployment. I got some file in use errors before so stopping the app prevents that. You might want a staging slot to prevent down time, but it’s a bit overkill for this blog post.
Now release! Just by clicking or again commit some code. If everything went well as it should, you should see this beautiful message:
Next blog, maybe unit testing, maybe some database access…. maybe both!