{"id":25255,"date":"2018-06-08T17:33:00","date_gmt":"2018-06-08T17:33:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/premier_developer\/?p=25255"},"modified":"2019-04-11T05:31:22","modified_gmt":"2019-04-11T12:31:22","slug":"devops-for-vms-with-vsts-and-octopus-deploy","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/devops-for-vms-with-vsts-and-octopus-deploy\/","title":{"rendered":"DevOps for VMs with VSTS and Octopus Deploy"},"content":{"rendered":"

In this post, Premier Developer Consultant\u00a0Jafar Jaffery<\/a> shares insight into how to deploy web applications to virtual machines using Visual Studio Team Services and Octopus Deploy. You can use Octopus Deploy in conjunction with VSTS to deploy both on-premises or in the cloud in a repeatable and reliable way.<\/p>\n

\n

Problem Statement<\/a><\/h3>\n

The Development team just finished work on its new feature and now needs that feature deployed to the Testing environment so that the Product team can validate the changes. Enter the Operations team. They are going to remote into the individual web servers and download the package with the changes, extract it and copy it to the target folder. After that, they\u2019ll make all of the IIS configuration changes on each individual box. But this raises a few concerns \u2013 how do other team members perform this deployment in a repeatable manner? And how can we make this manual and boring process less error-prone so that we don\u2019t have to troubleshoot simple deployment mistakes? Additionally, do the developers have to wait for the Operations team to handle their deployments every time they have a change, or is there a fire and forget solution they can use to do this automatically whenever they are ready to push their changes? DevOps solves these problems for us by having teams work closer together and introducing these \u201cauto-magic\u201d mechanisms, which is what I\u2019ll be covering that in this post.<\/p>\n

Overview<\/a><\/h3>\n

In the world of DevOps, Visual Studio Team Services (VSTS)<\/a> offers a very robust and versatile platform that will serve as a foundation for your application deployment and automation needs. It has the capability to do end-to-end pipeline deployments for both on-premises and Azure IaaS Cloud infrastructure. VSTS also has an extensive marketplace of 3rd<\/sup> party offerings to augment its capabilities.<\/p>\n

In this post, I will walk you through an overview of how VSTS is used alongside Octopus Deploy<\/a> to deploy .NET applications to a traditional VM server infrastructure, be it on-premises or in the cloud. This will give you repeatable and reliable deployments of your application every time, to every environment. As a note, this will be a basic setup consisting of a build (MVC web application), unit tests, automated deployment of code to a lower environment (\u201cTesting\u201d in our example), and promotion of that code to an upper environment (\u201cProduction\u201d in our example). Database deployments will be covered in a subsequent post.<\/p>\n

VSTS will be handling the build\/CI automation part of the process and will work with Octopus Deploy to handle deployment orchestration. The Octopus ecosystem is comprised of a central deployment server, along with \u201cTentacle\u201d agents that run on any target VMs where deployment will take place. The diagram below illustrates this flow:<\/p>\n

\"image\"<\/a><\/p>\n

VSTS<\/a><\/h3>\n

Setting up the VSTS\/Octopus Connection<\/a><\/h4>\n

Inside VSTS, install the Octopus extension from the marketplace, and then add a new Service Endpoint for Octopus Deploy. You will need an Octopus API key for the endpoint, which can be generated from the Octopus Deploy web portal. Detailed instructions for these steps can be found here<\/a>.<\/p>\n

Setting up the Build<\/a><\/h4>\n

The VSTS build will consist of the following tasks:<\/p>\n

\"image\"<\/a><\/p>\n

    \n
  1. Restore NuGet Packages<\/li>\n
  2. Build the solution<\/li>\n
  3. Run Unit Test<\/li>\n
  4. Package the solution into a NuGet package<\/li>\n
  5. Upload the package to the Octopus Deploy server. Note that you can alternatively upload to a NuGet repository.<\/li>\n
  6. Create the release number string for the Octopus release. We\u2019ll go with a combination of a date\/time stamp and build ID \u2013 [yyyyMMdd].[BuildId]<\/li>\n
  7. Create the Octopus release and deploy to the lower environment (\u201cTesting\u201d in this example).<\/li>\n<\/ol>\n

    For Octopus specific steps, detailed instructions can be found here<\/a>.<\/p>\n

    The build will be triggered using Continuous Integration within VSTS whenever any code changes are committed to the repository. This is significant as this will automatically do the deployment to the lower environment whenever any code is changed and checked in.<\/p>\n

    \"image\"<\/a><\/p>\n

    Octopus Deploy<\/a><\/h3>\n

    Key Concepts<\/a><\/h4>\n

    Before we setup the project that will deploy our application, let\u2019s explore some of the key concepts within Octopus:<\/p>\n