Fast Start: Infrastructure as Code using Azure DevTestLabs

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.

Let’s get started.

Pre-Reqs:

1. You’ll need a Microsoft Azure account (sign up for free today here)

2. VSTS account (sign up for free at www.visualstudio.com )

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.

dtl1

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.dtl2

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

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.

As always feel free to reach out with any issues.

TFS 2018–XAMLs back?!?

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.