Alot of folks understand that Infrastructure as Code (aka IaC) is a great idea and an advanced concept of DevOps. What alot of folks don’t realize though when they begin their journey that there are alot of tools and alot of different ways to start.

At Microsoft we have numerous ways to get started with IAC. One of the easiest ones is to take advantage of Azure’s DevTestLabs and VSTS (Visual Studio Team Services). Together these two technologies make it super easy to get started on the road to being able to deploy on-demand and anytime.

Next we’ll need a sample application to deploy. I added a simple ASP.net website to my git repo in VSTS along with two other important scripts.

Note: I’ve stored my sample project along with the two needed scripts in my GitHub repo located here.

Basically the file dtlvmtemplate.json is the templatized form of a web app which I downloaded directly from Microsoft Azure. The other script InstallApp.ps1 is a DSC piece of code which takes care of making sure IIS is installed, that ASP.NET is installed and configuring the website on this new server.

Steps to re-create this on VSTS.

1. Import the git repo into VSTS.

2. Next we need to setup a CI build in VSTS which will build the application AND publish the deployment scripts folder as an artifact so it’s available for Release.

3. With a successful build we need to setup a Release which will call the deployment scripts AND deploy our sample application.

4. And finally just add a call Remote Powershell on the newly created server to deploy the application.

As you can tell this is pretty quick and obviously a very simple example but it can easily be expanded upon for larger multi-tier applications.

Starting in TFS 2017 it was announced that XAML builds were being deprecated. No big surprise to anyone paying attention as they are an older build system which had to go at some point. However this was a HUGE blocker for alot of customers who want to upgrade but don’t/can’t invest the time to switch hundreds of build definitions from XAML to Task based. Now (due to customer feedback) it’s been decided to deprecate XAML builds but leave the functionality in there. I think its a great compromise…letting our legacy customers get the new features while not permitting them from upgrading directly.

In one of his recent blog posts Brian Harry describes in great detail the reasoning behind this deprecation and why it had to be done. He mentions that the XAML support will go away in VSTS by the end of 2018….one wonders if there might be built-in features to allow customers to continue to use XAML builds since TFS on-premise decided to “bring it back”.

In his own words:

We first introduced basic build automation capabilities in TFS 2005 and, over the years, it has evolved substantially. In TFS 2010, we introduced a major update which we now call “XAML build” because the build orchestration layer was based on the XAML workflow engine. As that got adopted, we found that workflow was just not the best representation of build processes – wrong granularity for build, not natural to extend for build, provides capabilities (like durability) that really don’t apply to build, etc. And, as we began to stretch beyond .NET/Windows into Mac, Linux, etc., it became clear that Windows Workflow was not the right foundational technology. In TFS 2015, we shipped another major update, introducing a simpler, cross platform pipeline/task model.

Because the two models are so different, we have supported both in parallel to allow customers to continue to work (and even upgrade to new version of TFS) without interruption. By supporting both, in parallel, people have time to try out the new version, learn it and, where appropriate, adopt/migrate to it. We feel (and evidence based on usage shift) that the new build system is in good shape and ready for broad adoption.

The plan has been, and continues to be, to remove support for the XAML based build system from a future version of TFS and Team Services. I want to share where we are on that journey and what lies ahead. We know deprecating existing capabilities is painful and we never do it lightly. Unfortunately, we do need to make breaking changes from time to time and we try hard to make it as smooth as possible. Feedback is always welcome on how we could do it better.

Personally I think it’s a brilliant move to satisfy large customers. It show-cases how Microsoft continues to innovate and pivot as much as possible based on our customer’s feedback.

One of the many recent enhancements to VSTS (Visual Studio Team Services) is the adding of Deployment Groups back in 2017. However ever since they were added the next obvious question was: How do I share these across my Team Projects (similar to how Agents work across Team Projects). This scenario is useful in order to allow organizations to take full advantage of their infrastructure and maximize the return on investment in cloud technologies such as Microsoft Azure.

Much like Agents there is a “Deployment Pool” which is actually the mechanism which allows the sharing across Team Projects. Initially there was a one to one mapping of Deployment Pool to Group but customers quickly realized the potential use for these groups.

There are some requirements that must be met before these Deployment Pools can be shared/used:

1. The user sharing the Deployment Pool must be a user for the pool.

2. The user sharing the Deployment Pool must have permissions to create a Deployment Group in the new Team Project where we wish to share it.

3. The new Team Project must not already have a Deployment Group backed by the same pool.

How to share the Deployment Groups/Pools?

1. Go to the Deployment Group in your existing TP and select Manage

2. Select which Team Projects you want to share these Deployment Groups with

3. Now when you navigate to the new Team Project you will see the Deployment Group listed under it (backed by the same Deployment Pool).

Hopefully this will help folks realize how versatile VSTS is and help someone get on the road to DevOps faster. As always if you have any issues don’t hesitate to reach out.

During your DevOps journey typically the first item you will want to do (after establishing a good process for the team) is setup a Continuous Integration (CI) build. What does this mean in practical terms? Basically TFS/VSTS has the built-in capability of running a build anytime code changes in a certain repository (or repositories). This is a great practice to institute as it helps minimize the possibility of having “broken” code in your protected branches.

VSTS (Visual Studio Team Services) has a great and simple mechanism to help promote this best practice. Below I will walk you through how to setup a CI pipeline (we’ll discuss Continuous Deployment [CD] in the next follow-up post).