How to Set Up Visual Studio Online for Continuous Deployments

Here at Diagram, our team of designers and developers are constantly working on a variety of projects, and it’s important for us to be able to coordinate our efforts, through both project management and management of the code we utilize. In my last blog, I gave a high level overview of the components we use to build and deploy our applications; now, we will take a deeper dive into configuring Visual Studio Online (VSO) to build and package an ASP.Net application for deployment.

VSO Project Setup

The first part of setup is to create a new team project in Visual Studio, or navigate to an existing one. Then, from the project menu, select the code section, and choose the best cloning options that meet your needs. For us, it’s Clone in Visual Studio, as seen below:

For new projects, navigate to the team explorer window in Visual Studio to choose clone repository and enter the desired path on your local machine to store the project code:

Once the project is cloned, you will need to create a new solution for your application, with Create new Git repository checked:

Now that the project is set up locally, you can add your files and NuGet packages as normal. For existing projects, you can simply open the solution file.

Required NuGet Packages

For the project to be packaged, a couple NuGet packages need to be added to your project:

• OctoPack
• OctoPack.PropsConfig

These packages will simplify creating a deployable NuGet package from the Octopus Deploy server. After those packages have been installed, add the following text to the OvermanGroup.OctoPack.props file below the “<!-- Place OctoPack properties below this comment... -->” XML comment:

<OctoPackNugetProperties Condition="'$(OctoPackNuGetProperties)' == ''">id=$(MSBuildProjectName)</OctoPackNugetProperties>
<OctoPackPublishPackageToFileShare Condition="'$(OctoPackPublishPackageToFileShare)' == ''">$(build_stagingDirectory)</OctoPackPublishPackageToFileShare>
<OctoPackPackageVersion Condition="'$(OctoPackPackageVersion)' == ''">$(BUILD_BUILDNUMBER)</OctoPackPackageVersion>

These lines of code instruct OctoPack to create a NuGet package using the name of the project, instruct the build server to place the package in the staging directory, and set the version of the package to match the version set by the build server (the default format is $(date:yyyyMMdd)$(rev:.r)). This creates a package version number that includes the date built and build attempt (e.g. 20160328.1).

Additional NuGet configuration

If the solution requires packages from another NuGet feed, such as Episerver, then you will need to create a .nuget folder with a nuget.config that contains the additional package sources. Below is an example config for referencing Episerver packages:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <solution>
        <add key="disableSourceControlIntegration" value="true" />
    </solution>
    <packageRestore>
        <add key="enabled" value="True" />
        <add key="automatic" value="True" />
    </packageRestore>
    <packageSources>
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
        <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
        <add key="EPiServer" value="http://nuget.episerver.com/feed/packages.svc/" />
        <add key="EPiServer Addons" value="https://nugetaddons.episerver.com/feed/addons.svc/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
        <add key="All" value="(Aggregate source)" />
    </activePackageSource>
</configuration>

This file must also be added to Git and synced to the remote repository.

Setting up continuous integration

Continuous Integration is simply an automated process that builds the Visual Studio solution when an event occurs, such as syncing your local code changes to the remote VSO Git repository. In VSO, this is accomplished by accessing the Build section, and creating a build definition.

To get started:

1. Click on the green plus icon to open the Create new build definition wizard, and choose Visual Studio.
2. Select the repository and branch for the source code.
3. Check the Continuous Integration checkbox to setup a build trigger for check-ins on the branch selected above.
4. Select Create.
5. The build definition should contain at least the following build steps:
   1. NuGet Installer – restores missing NuGet packages during the build process on the build server
      • Default values are good.
   2. Visual Studio Build – builds the solution
      • Set MSBUILD Arguments to /p:RunOctoPack=true
   3. Visual Studio Test
      • Default values are good.
   4. NuGet Publisher – step added manually
      • Set Path/Pattern to nupkg to $(build.stagingDirectory)\*.nupkg
      • Set NuGet Server Endpoint to the Octopus NuGet values by selecting Manage and adding a new service endpoint for Octopus Deploy using the Generic option and setting: Connection Name, Server URL, and Password/Token Key.
        
        More information about these values are found at http://docs.octopusdeploy.com/display/OD/Package+repositories.
   5. Remove any additional steps added by the default template such as Index Sources & Publish Symbols, Copy Files, and Publish Build Artifacts.
   6. Click Save.

The order of the build steps is critical, since you will want to restore packages before building in order to avoid build errors. Also, during the build process, we pass in the additional argument to run OctoPack to set up the publish process. Then, you will want to run your tests for the solution before you push your package to Octopus Deploy for deployments. The NuGet publish path of $(build.stagingDirectory)\*.nupkg is also important, since you don’t want to push all the restored NuGet packages to your Octopus Deploy feed, as they are unnecessary and take up additional hard drive space.

Service Hooks

VSO also has a great capability of setting up Service Hooks, which can be integrations for many systems when events occur. One great use of this is integration is with your team communication tool. At Diagram, we use Slack, so we’ve set up a service hook for Slack to post notices to a continuous-deployment channel for build complete events to notify our team of build successes/failures. Octopus Deploy also has a custom step template we utilize to notify of deployment successes/failures.

I hope you’ve found this information helpful, but if you have any questions, please feel free to contact us or leave a comment below. In my next post, I’ll take a deep dive into setting up the Octopus Deploy project to finish the continuous deployment from the published NuGet package. Thanks for reading!