If you have been tracking Azure at all lately you know that it is growing at breakneck pace. Microsoft has really turned up the volume on their enterprise cloud at all levels. Just diving in can sometimes be a rough experience. Azure is a wide open field with many paths to solve your problem. I would like to show you the path I have found to get my release management up and running for my complex micro-modularity and microservices.
In the last post we created an ASP.NET Project for Visual Studio Team Services (VSTS) Release in a minimal way. Now we will check ‘the check box of continuous integration’ and ‘push the button of continuous deployment’. Then we will add a second deployment environment to get your creative juices flowing.
So to be clear, there is some configuration you need to do upfront that I won’t cover here. Some of the setup is clearly part of the awkward dance of preview services. But if you want to get ahead of the curve and take advantage of these services, I can attest to it being well worth it. They only need to be setup once.
- Create an Azure Build definition.
- Create an Azure Release definition
- Deploy Azure Resource Group containing a Web Site
- Configure a second environment
For the purpose of this tutorial you need the following:
- Project to Deploy with Azure Resource Templates (follow tutorial, or fork it)
- A VSTS account with a project, the RELEASE hub enabled and version control system (VCS), it is easy enough to use the hosted Git or Github or most any Git repo visible to the Internet.
- A service end point configured in Team Services or TFS with rights to connect to your Azure subscription.
- An agent that is capable of running the deployment tasks. I am just using the one on VSTS.
- if you are using GitHub for version control you can connect it using a personal access token
Once you have the above resources you should be able to walk through the rest of this Release Management tutorial for Visual Studio Team Services.
Azure Build Definition
In your project click over to Build. You will see a nice little green plus on the lefthand side that will create a new build definition. Select the Visual Studio template and select the repo you are going to use.
If you are using github you can specify it later when you edit the configuration. This template gives you a nice list of tasks that will handle our simple situation. It is easy to add and remove tasks. I would encourage you to do so when you finish this tutorial. The build config is very robust, able to trigger on-prem builds and even using crazy automation tools like like Ant, Gradle, Grunt, Gulp, Maven… go nuts.
The easiest thing to do is use the Git repo built into the project, but I am going to build the example code from GitHub. You can follow the link above to connect it to your VSTS account for use. The configuration looks like the following using the built-in VCS or Github.
Web Deploy Package
To make the deployment package MSBuild basically deploys to a zip file. To trigger this you need to add ‘MSBuild Arguments’ on the Visual Studio Build step. In that field type
/p:DeployOnBuild=true;PublishProfile="Web Deploy Package"
After you make the change, click save. A great feature of the system is version controlling the builds. You allowed to rename the build here and add a comment. If you comment every save you create a rich history of changes, each of which can be scrutinized on the History tab.
Continuous Integration (CI)
At this point verify you have checked ‘the check box of continuous integration’. Note that you can also schedule builds if you like ‘Nightly’ instead of ‘Continuous’.
Now comes the fun part: Click and watch it do it’s thing. When it is done you will find that these logs are saved and you can brows the artifacts created or download them as a zip.
Azure Release definition
Now click over to the Release tab. Release uses the same engine as build, so you will see many of similarities, and you can do many of the same tasks. Layout should be familiar, so click the green plus sign over on the left that says it is used to ‘Create a release definition’. Choose the Azure Website Deployment template and click ok. This starts you out with a single environment that has a couple tasks.
Here the term ‘environment’ means no more than a single set of tasks, variables and sign-offs that can be strung together to make an automated release process.
You will note that you are encouraged to test often since the second task you are given is a test task. I personally run Unit Tests during build and Integration Tests after a release. If you wanted you could even have a little sanity test to run when you release to production.
First it is good to configure the Azure Web App Deployment task so you can save. Simply select your Azure Subscription endpoint, give your app a name, and select a location near you for now. Give the release config a name and click save.
Right now you could click deploy and the thing would just go and use defaults and you would get a website in your Azure account. However, you would not have any real control over how it would be billed and it would use whatever web.config you checked in. So in this step we will take control of all of this with a couple little JSON files.
Click . Under deploy click Add next to Azure Resource Group Deployment. I will admit when I first saw this I thought it sounded grand an complex. However, a couple clicks later I was elated with how simple it is.
When you click close you will notice the task is incompletely configured by default and at the end of your tasks. Make it the first task by dragging the task to the start of the list. Then select your Azure Subscription service endpoint (I use a Service Principal for this). Then name the resource group. Later when you master variables you can name everything by convention using an environment specific variable. I always add ‘-resource’ to the resource group name for additional clarity.
Now click the ellipsis on the Template line. It will tell you that you don’t have any build definitions linked. Click ‘Link to a build definition’ and select the build definition you made earlier as the Source and click the Link button.
Now you have a tree of the artifacts created by that build when you ran it last. The files you want will be under ‘drop’ and the folder name you gave your Resource Group project. Then under bin/Release/Templates select the WebSite.json file and click OK. Assign the Template Parameters value by clicking the ellipsis again, browsing to the same location and selecting the WebSite.parameters.json.
Now you are to the point where the magic starts and where things really started to click for me. Because you defined the website name and connection string as a parameter you can assign those via the Override Template Parameters field. In this field set your values like this:
-hostingPlanName "myPlanName" -websiteName "myWebsiteName" -connectionString "Server=tcp:mydatabase.database.windows.net,1433;Database=myDbName;User ID=myUsername;Password=MyPassword;Encrypt=True;"
One last thing to check before you release is that your Locations match between the Resource Group Deployment and the Web App Deployment. Then click Save.
Now the point of all this is to get you to continuous deployment. To enable this click the Triggers tab and check the check box, select your artifact source and select your environment. Then click save. Now when you check in a change, it will build. When done building it will release.
To give it a test without checking anything in click the release drop down and select Create Release. You can choose the artifacts from the release you did earlier and select the environment you just configured and click create. If the process succeeds you can verify by viewing the Resource groups in the Azure Portal. The great thing about resource groups is now, to remove everything you just released to Azure, simply delete the resource group. To deploy it again, make a commit or release it manually.
The great thing about using the resource template is that if you make changes the environment will be updated to reflect those while you keep the progression of the environment under version control.
Configure a second environment
To understand why I think Release environments are cool, click the ellipsis on the Default Environment and ‘Configure variables’. You will notice there are a variety of them predefined. Lets create one of our own.
At the bottom of the list click Add Variable. Name it ‘websiteName’ and give it a value you like. Click OK, and go back to your Resource Group Development task. In the Resource Group filed type:
Then in your Override Template Parameters put $(websiteName) after -websiteName. Select the Azure Web App Deployment task and put the variable $(websiteName) in Web App Name field.
For a second, imagine you have a much more complex release environment you have configured. Now, click the ellipsis next to Default Environment again and click ‘Cone environment’ and call it something like QA.
Now configure variables on that environment and change value next to websiteName, perhaps appending ‘-qa’ or something. Click ok and Save the definition. I don’t know about you but the first time I did something like this I giggled enough to make everyone in cubes around me feel uneasy.
Where to go from here
From here you can add more variables, parameter and infrastructure. Add a database or other services and make a self contained set of services so you can spin up tests of all sorts. There are many tutorials out there for expanding on your JSON templates and great functionality built into Visual Studio (maybe Code too) to help you edit these configurations. I would be interested on where you personally take things from here.
In a post in the future up I will dig a little deeper into how I have overcome the issues of managing many tiny libraries using private NuGet repositories and multiple Git repositories.
After looking at VSTS Release, how does this compare to other tools you have used?