Tokenizing Angular applications to work with VSTS Release Management Part III

You have found part 3 of my article on Using VSTS to tokenize Angular application builds and deployments. In Part I, I explained the scenario, goals, and solution. I walked through configuring and running locally in Part I. InPart III covered building the package to use in a release pipeline. In Part III, I will show how to use the build artifacts, replace the token with the environment settings, and deploy the Angular 2 app to an Azure App Service Web App.

The VSTS release definition contains the following steps. I will highlight each of these.

The Copy Files task copies the files from the web artifact to a temporary folder where we will replace the token.

VSTS doesn't have a built-in token replacement task so I looked in the VSTS Marketplace for a task to use. I found two. The first I looked at was a tokenization task that was part of the Release Management Utility tasks. The tokenizer task worked fine except that the tokenizer task searches the files for tokens with two underscores before and after the variable name. For example, it looks for tokens like this __apiUrl__.  It turns out that webpack uses variables with the same format that causes the task to take a long time to run. With this task there isn't a way to change the token search pattern.  The second option was the Tokenization task.

This is similar to the other task except this has the ability to change start and end token placeholder. In the task, I also specified the source folder and in this case, there was only one file to search and replace. This tasks no executes very quickly.

Each environment can contain a list of variables. In this case the tokenized value was ___apiurl___, so the tokenization task will search the file for the specified pattern. Once it finds that match, it will look for a build variable name that matches without the prefix and suffix. Then it will replace the token with the value of the variable.

Now that the value has been replaced, we need to take the Angular output files and package them so they can be deployed to Azure. There are a lot more options to deploy in VSTS but I had to make this work with TFS 2015 Update 3. I decided to write a small PowerShell script to take the output and created a Web Deployment package. To do this I used the PowerShell++ task. This task is also part of the Release Management utilities. You can use the regular PowerShell task but I used this to have an inline script.

In the script textbox, enter a script similar to this. This takes the webtemp folder and zips it up into the web.zip file.

set-location "c:\Program Files (x86)\IIS\Microsoft Web Deploy V3"
$sourcePath = "$env:AGENT_WORKFOLDER\webtemp"
$destPath = "$env:AGENT_WORKFOLDER\webtemp\web.zip"
cmd.exe /c $("msdeploy -verb:sync -source:contentPath=""$sourcePath"" –dest:package=$destPath")

‍
The last two steps deploy the web and webapi apps to the corresponding Azure Web App and Api App sites. The Azure app service deployment task has changed names and the options available it seems like more than any other tasksince the new build system was released with TFS 2015. This screenshot shows the latest VSTS version.

When deploying to Azure, there are two models to connect. The classic portal uses Azure Service Manager (ASM) and the new portal uses Azure Resource Manager (ARM). Most functionality has been moved to ARM including the Azure App Services. However, with TFS 2015 Update 3, even though there are other tasks that use ARM, the Web App deployment task only supports ASM. The good news is that you can use either model to deploy to the App Services. So, in TFS 2015 Update 3, we create a service connection to ASM for the task. Using the deploy task to deploy to your ARM App Service will work.

I hope you found all three parts of this article helpful and are able deploy Angular apps as part of your release process like your .NET applications. If you have any questions. Feel free to contact me on Twitter at @mikedouglasdev.