Click here to download

The extension can be installed from https://marketplace.visualstudio.com/items?itemName=PeterRombouts.autotagging-extension

The working is pretty simple; enter the values for your subscription, and resourcegroup, and then add the tags.

The tag pairs should be entered, one pair per line, comma separated. The extension will add these tags to all resources in the given resource group, and will not do anything to the existing tags.

Remarks? Please do give feedback! The project is available on Github if you want to contribute!

Many developers have Powershell or other scripts in place, that fix this problem, but I want to highlight an extension, which is freely available and does this for you, for free!

This extension enables you to use the ARM Deployment outputs in your VSTS environment.

This step will use the last successful deployment within the selected resource group. If this deployment has outputs, all of them are copied to VSTS variables by the ARM Output key.

These outputs can then be used by default VSTS ways: $(same-key-as-in-arm-template)

Usually this task is ran directly after the ‘Azure Resource Group Deployment’ task.

So my pro-tip; Stop using your own scripts and implement this handy extension!

PS: On a sidenote, Kees is also a great guy, give him a tweet after you install this in your project

Link to Marketplace: https://marketplace.visualstudio.com/items?itemName=keesschollaart.arm-outputs
Kees on Twitter: https://twitter.com/keesschollaart

LogicAppTemplate is a PowerShell commandlet that makes is very easy to get the content (even automatically) of the app and save it to disk.

The usage is very simple, open up a PowerShell window and execute the next command:
Check out this gist

Big thanks to Jeff Hollan who authored this!

But, when you add more and more LogicApps your JSON file will grow and you might be better off putting each LogicApp within its own JSON. Not to speak of the parameters running wild within your files…
This post will explain how to set this up, and what is needed in your VSTS builds to enable the deployment of all the linked apps.

Multiple LogicApps

When you add a LogicApp to your existing project, you can expect a settings screen like below:

The result is a new set of params and a new resource:

Splitting up the LogicApps

To split up the files, several steps need to be taken.

1. Move the LogicApps from the main JSON to separate files
2. Update the main JSON file to point to the new separated files, and add parametes to work with artifacts/SAS during deployment
3. Update the parameters file to set names and other settings

1. Move the LogicApps

The first step of separating the files is to create a folder (although not necessary, highly recommended because of readability) within your solution, and move the separate LogicApps into those folders.

2. Update LogicApp.json and add parameters

To link these new JSON files, the LogicApp.json needs to be updated, like in the following gist. Three new parameters are added to the JSON. The first two are used to link in VSTS to the blob storage that will hold these templates.

https://gist.github.com/prombouts/f541e53fecc95a95d0f8940710cd15b7.js

3. Update LogicApp.parameters.json

Finally we have to edit the parameters file. The next gist show how the default setup is, when creating LogicApps within one single JSON:

https://gist.github.com/prombouts/105351d5bbc5a364c0cfc2b1d9184160.js

The next example show how to create a new configurationparameter object to hold the settings for the separate files. We will refer to these in the LogicApps within the folder.
https://gist.github.com/prombouts/eab9aa4963a09df052718cb3dd62716a.js

Setup VSTS build

To leverage these templates, some additional steps need to be taken in VSTS. For example the artifacts and SAS tokens should be passed in as parameters.

Build step

In the build step, the templates should be copied to blob storage. After all, the linked templates only work with full URLs so we must place these in storage. Note the output parameters to be used in the next steps when validating the template:

Make sure you publish the artifacts to a folder, so you can pick these up in the release step!

Release step

Finally the release should be setup. In the first step the files are copied to blob storage, and the output parameters are used to capture the sas tokens.

Secondly the actual deploy uses the parameters from the previous step and deploys the actual apps to Azure.

Conclusion

Setting up the pipeline with linked templates is not difficult, but will take more time to setup properly. When everything is in place, adding more templates is very easy and the separation of the various apps in separate json files will increase maintainability and readability. It will also help you share your templates with your peers.

Feel free to ask me anything on this subject; drop me an email or contact me on Twitter.

Manual uploading static content

Using the Storage Explorer, it is easy to create a blob container, and drag-and-drop your static files, like in the screenshot below:

Highlighted are the file extension and the Content Type. When uploading via drag-and-drop the Content Type of the files, like HTML and CSS, is automatically set by extension. As a result, you can open these files in your browser and view these as webpages.

Integration with VSTS

If these files are copied using the Azure File Copy task, all Content Types are default set to application/octet-stream. Obviously this will result in a download of the file, instead of serving it as a webpage.

Solving this issue is easy, seen in the screenshot below:

Simply add /SetContentType to the Additional Arguments box and the copy task will automatically set the Content Type, according to file extension,

Conclusion

When you are not able to serve HTML/CSS or even JS files hosted in Azure Blob storage, check the content type using a tool like the Storage Explorer. For automatic content type resolution, add the argument /SetContentType.

For more info on AzCopy, see http://aka.ms/azcopy.

When deploying your WebApp to various on-premise environments from VSTS, you can use Web.config transformations for separation of your various variables. But, sometimes, the *.Config transformations do not meet your needs.

Web.config transformation

For most .Net developers, using transformations is a standard procedure to separate your Debug and Release settings while deploying from Visual Studio. It is fully integrated in Visual Studio and is easy to use when deploying or creating packages from your code. These transformations can also be used within VSTS builds, but the disadvantage is that all settings should be present within your solution and code-base.

Take for example the following situation. Building a generic SQL server backed WebApp, releasing this app to your localhost, and Test, Staging and Production environments.

Testing your transformations is easy with the free online tool Web.config Transformation Tester.

In this example, a simple transformation can only be setup using more than one transformation if there are more than one database connection strings. In Visual Studio this can be resolved using the example below:

The example above shows the Release config, with the transformation (matched by name) of a ConnectionString. This has some disadvantages. First of all, for every new setting, each transformation file should be extended or modified. Secondly, every developer has access to all the settings, even for the production servers.

Using tokens in combination with transformation

This is where the tokens come in, and help you separate the settings of all different environments with your code-base. The transformation still can be used, but now we do not insert the actual values but token placeholders.

First of all, we do not necessarily have to use different transformations for different environments. In this example we will run Release builds for all environments, Test, Staging and Production.

Setup in VSTS

When running this example (using a Release build), the connectionString will be replaced with __ConnectionString__, which obviously will not work for your application. We will have to make sure these tokens are replaced with the correct values per environment.

You will need to install an extension by Guillaume Rouchon; Replace Tokens. There are more extensions that will do this task, and optionally you could write one yourself. I’m using this extension because it fits the needs perfectly and is free of charge.

After installing the extension, you should add the build step to your Build Definition in VSTS.

In the above example, the target files to process are all *Release.config files in all folders. For an elaboration of all values please see the documentation of the plugin. For this example the prefix and suffix are most important. These both are a double underscore, and those correspond to the value of our example __ConnectionString__ which is going to be replaced. You could choose any other string or character if you want.

Define variables in VSTS

The last step is to add the variables to VSTS. This is done in the ‘Variables’ tab of the Build Definition:

Please note that the variables do not have the prefix and suffix as used in the Web.Release.config files.

Everything is in place

When all steps are configured correctly, the system will execute the following steps:

• The ‘Replace Tokens’ extension will replace the __ConnectionString__ in Web.Release.Config with the actual value set in the variables section of your definition.
• The build solution step will execute the transform, as it would normally do. But in this case the first step has changed the token with the actual value to be deployed into your application
• Publishing your application with the correct ConnectionString in the Web.config ensures the target application will use the ConnectionString as defined in your Build Definition variables.

Conclusion

Using this setup, you are able to move the actual settings normally contained in your transformation files to your build definition in VSTS. In a fully automated CICD pipeline this enables you to shield settings from developers, and enable you to stop builds on missing variables.

Another advantage is that if a new environment is needed, like a Demo environment based on Production, only a Build Definition has to be added with new variables, and no additional transformation files are needed in your code-base.