0 Comments

Part 1 – General Overview & Account Structure.
Part 2 – Setting up the Azure and Visual Studio Online (VSO) structure and maintenance.
Part 3 – Setting up the Azure Environments with ARM and PowerShell.
Part 4 – Setting up Build Servers.
Part 5 – Setting up Continuous delivery (CD) on CI Development builds.
Part 6 - Setting up Release Manager for Dev nightly, QA, Stage and Prod deployments.

Part 5 - Setting up Continuous delivery (CD) on CI Development builds.

Now we have a build server (see part 4) we can now setup our CI build and our Continuous deployment build to the development server. We have several options on how to do this:

- use Azure websites inbuilt “Continuous Delivery” from VSO. This is great for simply deployments, but as we start adding more complex features to our enterprise apps this is unlikely to suffice going forward.

- use VSO Resource Group deployment functionality from the vNext CI build. Unfortunately this is not an option available to all of us, see Abrish's comments on this MSDN article, hence until this is fully released we need something else.

- User VNext for CI and use XAML build and Release Manager for CD on a rolling build basis. We will be using Release Manager throughout the rest of our pipeline to production, although not ideal due to the performance overhead, especially for CD, this is the only real option available.

We chose to implement the last point as we felt it offered us a gentle way into the new build system while still giving us full compatibility with the functionality of Release Manager we required. To do this we first require to setup a vNext CI build from VSO. To do this:

1). First open up the VSO web interface and navigate to the “Build” tab. Click on the green plus button to create a new build template. Choose visual studio and click ok.

image

2). You should now see the New Build definition page. As this is for CI purposes only, we can delete the “Index sources…” and “Publish Build Artifacts” steps from the default template.

image

image

3). In the “Visual Studio Build” step select the “…” button next to the Solution and navigate to your Dev branch and in turn select the .sln (solution file). I also prefer my builds to be clean for every build, so I enabled the checkbox “Clean”

image

4). Now select the Visual Studio Test step and expand Advanced options. To better encourage best practice check the checkbox “Code Coverage Enabled”. If your unit test projects are in the same solution as your other projects you should not need to change the default “Test Assembly” location.

image

5). Now click on the “Repository” tab and change the cloak location for your build folder. In my case this is a folder inside the dev branch.

image

6). Now select the Triggers tab and enable “Continuous Integration (CI)”

image

7). Now select the “General” tab and change the Default Queue to the Build Server group we setup in blog post Part 4.

image

8). We are now good to go, click the Save button, give it a name, and check in some changes to test. Any issues please make sure you do not have NuGet packages checked in with your solution and that the “Restore NuGet Packages” checkbox is enabled on the Visual Studio Build step.

image

Summary:

We have now setup our CI build for our project, but still need a way of Continuously Deploying it to the given Azure Environment. In the next article I will discuss how this can be achieved currently with Release Manager 2015 on VSO while we wait for Release vNext to be released by Microsoft.