Friday, July 3, 2015

My first Visual Studio Online Extension is live!

One of the many privileges of being an ALM Ranger is that you get the chance to participate in private preview programs where you work closely with the product group.

The latest opportunity was around the new Visual Studio Online Extension model. The new Extension model allows you to create your own extensions that plug directly into the VSO web access.

I started out with a simple extension: Folder Management. This extension allows you to create new folders directly from Web Access in both TFVC and Git repositories.

And I’m very pleased to announce that my new extension is now live! The code is at GitHub and will be completely open source from now on. There is also a blog post at the ALM Rangers account with some more details.

If you want to install the extension on your account, please join the Visual Studio Industry Partner Program. This is completely free at the basic level and will give you access to the new Extension model.

Questions? Feedback? Please leave a comment!

Monday, June 1, 2015

Slides from my TechDays 2015 sessions

Last week we had the TechDays here in the Netherlands. I was asked to deliver two sessions and two Ask me Anything sessions. A lot of attendees asked me if they could find my slides somewhere.

For those of you, here they are:

The two Ask me Anything sessions where recorded and will hopefully be available on Channel 9 later this week (I’ll post the links when they’re online). I love the concept of the AMA sessions and I hope to see them again next year.

If you have any questions on my sessions or would love to have them delivered at your place sometime (in person or online) just leave a comment!

Saturday, May 23, 2015

Azure Dev/Test labs preview is getting started

Today I woke up to an email inviting me to the new Azure Dev/Test Lab preview program. The preview program can start any moment now!

I’m really excited about this new feature. Especially when it comes to Application Lifecycle Management and Azure, Dev/Test is something a lot of my customers are interested in.

While working in the preview program, you get to directly interact with the product group and the team who’s building the new features. This means you learn from the people who really know it and you have a change to influence the direction of the product!

If you want to know more about Dev/Test labs checkout my previous blog post or Claude Remillards talk on Build (at 18:30). And of course you can also apply for the preview program.

Questions? Anything you would love to see in the Dev/Test labs? Please leave a comment!

Monday, May 18, 2015

Have you seen Build vNext?

Build is an important part of Application Lifecycle Management. Every DevOps pipeline starts with a Build. Visual Studio Online and Team Foundation Server use the XAML based build system for some time now. I’ve used this system in a lot of scenarios, ranging from small applications to complex scenarios with a multitude of customized builds working together.

But now that I’ve seen the new build system and had some time to play with it I’m completely sold. In this post I want to give you a quick intro to Build vNext and show you what it’s all about.

Why a new Build system?

The old build system is based on Windows Workflow Foundation. Microsoft created a set of components that you can use to create build templates. You can also create your own components (such as the Code Metrics I blogged about) and add these to your templates. A template could become very long. The following image shows you the outline of the default template that ships with TFS 2013.

An outline for the Default XAML build template

These Windows Workflow Foundation builds are run by what’s called a Build Controller and a Build Agent. The Agent does the actual work, the Controller manages one or more Agents and distributes the work to them. The Controller and Agent can only run on Windows. This means that cross platform builds, for example build an Xamarin app on Linux and Mac, are not possible out of the box.

Another limitation is that a Controller is linked to one, and only one, Team Project Collection. This means that sharing a build infrastructure between different collections is impossible. This required careful planning and sometimes resulted in customers having multiple build controllers without any real need for it.

Builds are configured by a build definition that uses a specific build template. These build definitions contain all the settings for your build such as which code to build, which tests to run and what do to with the results. The build definitions are not stored in version control. This means there is no audit trail and no way to go back to a previous version.

That’s enough info on the old build system. Let’s look at how the new Build system solves all those

Introducing Build vNext

While working on this post, Build vNext is now available in public preview on Visual Studio Online. If you go to your VSO account (and if you don’t have one, please create one! It’s free) and select a project you will see a new tab in your menu: Build Preview. This Build System will also be the default build system that’s shipped with Team Foundation Server 2015. Of course the XAML builds will be there for backwards compatibility but whenever possible, the new build system is recommended.

Configuring everything that has to do with your build definitions is now done from Web Access. This means you don’t have to use Visual Studio anymore for configuring builds, immediately making the build system configuration cross platform. Everyone with a browser can create a build.

Builds are no longer based on complex build templates. Instead, a build is simply a list of tasks. Tasks can be anything from running a Visual Studio build, executing a set of tests, calling a PowerShell script or even a custom task you create yourself. In the old build system, creating build tasks required a far amount of knowledge (if you look at you find some extensions created by the community). Fortunately, the new build system is very extensible and much easier then the old one.

A list of tasks that form a new build

Build tasks are essentially a JSON file shipped with other required files (like a PowerShell script). The JSON file describes your tasks with things like a name and description. It defines the  parameters that are required to configure the task and finally it contains the actual logic that needs to run when the task is executed. And best of all, there are plenty of examples already! With Microsofts new open-source focus, it shouldn’t surprise you that the build tasks are developed in the open at Github:

So, a build is a list of tasks. In addition to the tasks and their configuration, you can set numerous other properties on a build definition such as variables that you want to share between tasks, retention policies (meaning how much finished build results need to be kept around) and the triggers that should start a build. If you look at the next figure, you will immediately see a difference with the old build definition: there are checkboxes instead of radio buttons. This means you can now have a single definition with multiple triggers. Previously, you would have to clone your build definition and configure a different trigger each time to achieve this.

Selecting multiple triggers for a build

Build definitions now also keep track of their history. Any change you make will be saved as a new version. You can view the history of a build definition and compare different versions with each other to quickly figure out what has changed.

A diff showing the changes made to a build definition

There are also changes in the way a build runs. Web Access will give you a live view of the output a build produces. This output is grouped in steps that you can easily navigate and is stored with the build result.

And of course there is something that has to run a build. This is done by the new build agent. A cross-platform, Node.js based runner that can be installed with a simple script on Linux, Mac and Windows. This way. Microsoft has taken the build system completely cross platform, allowing you to have a farm of different build machines that can all be used together.

How does the build system figure out which agent to use? This is done by setting Capabilities on the agent and Demands on the build. Capabilities are automatically discovered by an agent. So installing Visual Studio on a build machine will let the agent know that it can run Visual Studio Builds. This removes the need to manually tag build agents and then add those tags to your build definitions to make sure that a build ends up on the correct machine (if required you can add custom capabilities and demands). There is no concept of a Controller linked to a Team Project Collection anymore. So agents can finally be shared across collections! Does this mean there is no way to restrict agents or have some form of prioritization?

Fortunately, there is. Microsoft introduced the new idea of Pools and Queues. A Pool is defined at the level of your VSO account or TFS Application Tier. Pools can be shared across Team Project Collections. They are used to define permission boundaries. Queues are scoped to the Team Project level and belong to a Pool. This way, a build can be assigned to a queue and then run on Agent.

Configuring Queues and Pools

How can I start?!

Since Build vNext is in public preview on Visual Studio Online, the easiest way to get started is by using your VSO account. Here are some resources to get you started:
And that’s it for now! I encourage you to start using the new build system and if you have any questions or comments, you know where to find me!