Posted by For the final part of this tutorial on Azure Continuous Delivery, we will be setting up the actual Continuous Delivery. To review everything we have so far, we have Visual Studio Team Services, multiple Azure App Services for each environment we want to configure, and integration between Team Services, Visual Studio itself, and Azure. Actual Continuous Delivery happens primarily between Team Services and Azure, with the exception of code commits triggering builds automatically.
If you want to only have a single environment configured, there isn’t a whole lot more you need to do. As I’m sure you’ve noticed, there is an option under the App Service blade in Azure that says “Continuous Delivery”. Sure enough, you can use this to set up the Continuous Delivery. Again, since Azure is linked to Team Services, Azure should be able to automatically pull in most of the details available for your source code. Then, any time there’s code committed to the branch you select, it will trigger a build and deploy to that app service.
Now for the fancy multi-environment Continuous Delivery, we start off in Team Services. For an easy way to think about why this is, think that setting up the Continuous Delivery in Azure as to be for the App Service, while in Team Services, you’re setting it up for the solution. The first step is to set up a build definition.
Build definitions are set by going to the top bar of your Team Services website and clicking “Build & Release”. Immediately below that a second menu should appear, and if you are not already on that page, click “Builds”, and go to the “Mine” tab. On the right there should be a “New” button, and a window will pop up to create a new build definition.
On the first part of the form, you can select “ASP.NET Core (PREVIEW)” or “ASP.NET (PREVIEW)”, depending on your project type. After clicking “Next”, you can specify the code settings, including the Source, Repository and Default branch. The key setting comes into play here, where you must select the checkbox denoting “Continuous integration (build whenever this branch is updated)”. Click Create and you’ll be taken to the Build Definition.
Note that this doesn’t mean that Build is final. From what we selected in the form of what type of build it is, multiple build steps will be added. There is a Save button under the “build” tab, and you can give it a name.
Moving on, we still need to set up a Release definition. Click the Releases page in the sub-navigation bar. On the side, a list will appear of each release definitions. Click the Plus drop down and select Create Release Definition. Another form will pop up in a window. Select Azure App Service Deployment as your template, click next, and select Build, using your project and your previously set build definition. Again, it is key to here select to use Continuous deployment. Hit create and your Release definition will be be started.
Within your definition, you’ll see your environment set up, and your task to deploy added. You still need to set your Azure subscription and App Service from the details on the deploy task. These will get pulled in because, once again, Team Services is linked to Azure.
Once you finish configuring your Deploy Azure App Service step, you can click the drop down to “Add Environment”, and clone the selected environment, or click the three dots on an environment and select “Clone environment”. In the second environment, you can change the App Service that is targeted for deployment to point to the other instance. Additionally, through the use of tasks, you can do a number of things like unit test and run PowerShell scripts. You can also edit the name of the environment by clicking that name in the list of environments.
For the record, I personally like to have my commits (usually via pull request) to my master branch to be built automatically and pushed to a test environment. I put an approval stop (Assign approvers to pre-deployment) on the production environment deploy though, so that once it’s tested it can manually be triggered, rather than just automatically updating production.
So there you have it, a fully functional, automated, multi-environment Continuous Delivery solution. If you need more resources or found this guide to be not comprehensive enough, Microsoft Azure does have documentation available. HERE is a good place to start.