Continuous Integration and Continuous Deployment

It's 2018, and nobody deploys anything manually! Being a .Net developer, I have enjoyed discovering

It's 2018, and nobody deploys anything manually! Being a .Net developer, I have enjoyed discovering the power that Microsoft’s Azure and Visual Studio Team Services possess regarding Continuous Integration and Continuous Deployment (aka CI\CD). They're simple, automated and have a bunch of predefined templates. You just need to setup an Azure account, a VSTS project, check your code in Git or TFS and create a Build definition triggered by changes in your code and pointing to an app service in Azure. Sounds easy. Well, yeah, as long as you manage all the accounts yourself and your team works within conventional project types, yeah, it’s easy-peasy. However, let you make a step aside from the way so carefully paved for us by Microsoft (it's real life, in the end, not a demo session), and you are going to get some pain in the neck, no doubts.

 Let’s say you have a project that consists of two apps. One app is .Net Core 2.0 Web API targeting .Net framework and another one is .Net Core 2.0 MVC with a controller grabbing data from Azure Storage and serving Angular 5 project as static files inside the wwwroot folder. All this beauty is stored in a single Git repository in VSTS (having a single repo for three projects might not be the best option, but we got what we got as it often happens). You have to configure CI\CD with Azure App service where you have one web app for API and another one for the composite (.Net-Angular) Front-End part. The integration has to be done through an endpoint for it to be independent of individual user’s permission in Azure or VSTS. Ah, you also have to setup a continuous integration pipeline for SQL database...

 Without further ado, here is the walkthrough for this scenario.

 1) Integration through an endpoint

Endpoint is an Azure AD app that granted to contributor permissions at Azure resource group and registered as a Service endpoint in VSTS.

 Create and app in Azure AD

Name and sign-in URL are arbitrary; Application type must be Web app/API. Using VSTS URL just looks descriptive to me.  

Create a key and save it in a secure location 


Assign a contributor to this app in the Resource group where your web apps are added. It's important: if you assign a role on the service plan level or a web app level, you will be able to use this app as an endpoint from VSTS, but the list of web apps to choose will be empty. 

Select Services section from “gear” menu in VSTS 

Click New Service Endpoint and select Azure Resource Manager option 

Fill fields in the pop-up with information from Azure Portal

Upon filling in, all the fields click “Verify connection” to check whether it works and click “Ok.” 

2)      Web API Build and Release 

In VSTS select “Build and Release” -> “Builds” -> “New” 

Select Repository and Branch and click Continue 

Select “Empty Process” template (you could also select ASP.NET Core template as long as it's the closest option to what we are creating but let me just show you all steps in setting up your Build definitions) 

I have appended the name of the Build Definition with WebAPI to distinguish it from our other builds