As part of the process of introducing Continuous Integration (CI) / Continuous Delivery (CD) across the business, I had already configured a build and two releases for our ASP.NET Web API services. These releases were both to on-premise servers. One being a staging server and the other being a production server. As part of the migration to Azure, I had to create a new release that would deploy our services to an Azure endpoint. No problem I thought, as TFS 2015 has an in-built task for this. I duly created the new release, but came across a couple of differences when I queued a release for testing.
The first difference was that the build was failing with an error message stating that the build required a certificate. The certificate authenticates your on-premise TFS 2015 account with your Azure account, thus only allowing authenticated users to deploy into your Azure portal. The necessary details for creating the certificate can all be found in a downloadable XML file from your Azure portal. So I created the certificate and specified its name as part of the Azure Web App Deployment task.
The deployment kept failing however, with an error stating that it could not find the necessary build articles. For deploying to our on-premise servers you specify the build folder (containing the build articles created during your latest build) as the folder from which the deployment should look to find the files it requires. For deployments to Azure you need to specify the location and name of the zip file that the build has created (the deployment package). It took a little investigation to find this out. I couldn’t understand why two of our builds deployed without a problem, yet the Azure one kept failing, despite using exactly the same source folder.
I have now got a fully working deployment of our ASP.NET Web API services to Azure running under TFS 2015. We still deploy to our on-premise staging and production servers for testing (the term ‘production’ probably needs to be renamed to something else as Azure is the production endpoint now).
So whilst the process for deploying to Azure are broadly the same, there are some key differences to be wary of that will catch you out.
Looking to the future, I would like to make use of deployment slots and remove our on-premise servers completely. I would therefore need to create development, staging and production slots which would mimic our current deployment process. When you deploy to Azure, you can specify which slot you want to use, so this would be a nice way of deploying to different environments for testing before a deployment to production.