cd

Continuous Integration and Delivery with Visual Studio Team Services (Part 2)

This post follows on from part 1, where I walked through the creation of the CI part of our pipeline,  creating a Visual Studio Team Services build definition that was triggered by a checkin to our GIT repository. This the CD part.

The goal is to deploy automatically after build our .Net MVC website.

I’m going to start, in Visual Studio Team services, going into my project Binet and clicking on the releases tab. As we have no releases yet, it should look a bit like:

step2_1

Let’s create a new release definition – we now see the following dialogue.

step2_2

We just want a basic deploy of our code to an Azure website for this demo. Azure App Service Deployment is good for us. The other Azure App Service deployments are fun too, but maybe another time. Hit Next and now we’re creating a release definition. This is based on our build from earlier (unimaginatively called standard build). Choose this Standard build and check the continuous deployment box – that’s the whole point of this!

step2_3

Next it will take you to the environments tab. A complicated looking tab to choose a source and destination is how I like to think of it. Here we need to pick our subscription, and the name of the app service we want to deploy to, we’ll call it binet.

step2_4

 
As this is was my first time I also needed to hit authorise, when choosing my subscription; I don’t pretend to understand the consequences of this, other than you gotta do it.

step2_5

We also need to setup our source. This is the Package or folder part. By clicking the ellipsis we can select the (_PublishedWebsite) folder that was output in step 1 of the process and select the folder immediately under this, where our website files exist.

step2_6

The path that we’ll end up selecting is:
$(System.DefaultWorkingDirectory)/Standard Build/drop/_PublishedWebsites/NextFib

Hit save and our release definition is complete. Let’s force it to run manually to test if we did it right or not; choose create a release from the Release tab that’s against the release definition.

step2_7

This will bring up another dialogue, where you can pick a particular build to deploy. By default it’s displaying the latest build (number) available – this is the one we want. So accept these defaults and hit create.

step2_8

Much like the creating of a build, your request will be queued up and picked up as soon as an agent is ready. For me, a mere few seconds later and an agent picked up my request and the deployment build began.

step2_9

After a couple of mins it finished and… it failed. If things worked first time, how could you learn? Helpfully? I also received an email telling me about what a failure I am.

step2_10

Big plus here, is a very clear error message (way better than msbuild exited with code 1). It turns out you need to create an instance of the App Service in the subscription you picked in order to deploy to it. Doh! An easy problem to fix though. I hopped over to my Azure Portal and create an empty App Service entry named binet

step2_11

Let’s try that deploy again. Going back to visual studio team services, navigate to releases and kick one off again. This time…

step2_12

 

Yes – deployment was successful!
My website showcasing Binet’s forumla is now live and being hosted in Azure. Go check it out.

step2_n

 

After this I performed a couple of minor updates to the site, checked them into Github and verified that the CI worked and the CD deployed to the Azure App Services website. I appreciate this is a very simple example, but is one that can be built on. What I do like about this solution is having my entire infrastructure in the cloud; also it’s cost me nothing!