Connecting VSTS to Azure is not something well documented. You will see few articles that talk about configuring a step in VSTS build, some other article that talk about steps with the old Azure portal. After few hours, I realize that deploying VSTS code to Azure is more easy than initially thought. First, you need to create in VSTS a service endpoint. In the settings of VSTS, select “New service endpoint”. Multiple options are available, the one that is needed is “Azure Classic”. The name doesn’t matter of the connection your choose. What is important is the subscription id and name. I choose to authenticate with the publish setting file.
Once done, you need to go in Azure and search for “team” in the browse. Select the Visual Studio Team Service, and connect your MSDN subscription.
The last step is to select under your website’s setting the deployment configuration. You can select multiple sources, but only one at the time can be selected. Choose VSTS.
From there, if you push something, Azure will get the code, build and deploy.
Azure allows to create website’s slots once you have your website created. Before everything, what is an Azure website slot? Slots are a way to create a clone of your website on a temporary website. Having this clone let’s you test your code without affecting your production code. You can have custom application settings, like pointing to a second database if you want. It has the advantage to also warm-up without affecting your user. The first call to a website is always slower. With a slot, it’s slow on this one. You can configure to have this one warmed up completely before auto-swap back to the production, where your user see it. Or, you can manually swap it when ready, which allow you to do some manually testing on the slot.
The first step is to create the slot. This is a matter of less than a minute. You can do it directly on the portal.
The second step is to deploy to this slot instead of the main production one. This was the step that is not clear. You have to publish to a slot and then swap. To do so, you need to get the publish settings. This can be downloaded in Azure Portal. Just go on the main website, click slots, select the one you want to deploy and click Get Publish Profile.
This is how to deploy a website on Azure with slot. By publishing to a specific slot and then handling the slot manually or automatically (auto-swap). A special note, if you want to use Azure Deployment slots, you need to go in your website deployment slot and configure the Deployment directly on the slot, not the main website.
If you are using Visual Studio Team Services (VSTS) for your continuous integration (CI) you may want to run only specific tests. In the past, I had a project that were dividing tests that needed database and not. One was integration tests, the other one unit tests. In the CI you want only to run unit tests. The reason is that they doesn’t not require any infrastructure like databases, cached, third-party services or external API. That said, if you cannot specify an assembly name (or pattern) how can you tell the CI to run only the unit test?
VSTS’ build system can run the Visual Studio Test step with test filter criteria. This is where you can define which TestCategory you want to execute.
This is not really obvious from VSTS website what you can put there. The “i” icon gives you some information but this is quite limited. A better user interface (UI) would have been to have a quick cheat sheet available on the “i”. Nevertheless, you can type “TestCategory=YOUR_CATEGORY” where YOUR_CATEGORY is the one defined in the test.
At this point, you are almost done. I didn’t had any test category defined on any test since tests were divided by assemblies before. Now, they are all in the same. The quickest way to add test category to test was to go on each file, open these related to unit test and do a search and replace on open files. The searching query is for [TestMethod]. The replacement is [TestMethod][TestCategory(“UnitTest”)]. From there, you just need to commit and push you change and see the CI running the unit tests.