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

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 tfsbuildextension.codeplex.com 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: https://github.com/Microsoft/vso-agent-tasks.

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!

Monday, May 4, 2015

Things to do after Build

Do you know about the phony feeling when being a developer? That feeling that you actually don’t know anything and that you’re only pretending? Scott Hanselman wrote a post on this ’Exploring imposter syndrome in technology’ and apparently the feeling is not uncommon.

And I suffer from it. Especially after visiting Build! There are so many great things discussed and new features released that I left Build with the feeling that I should really study up on some stuff.

So without further ado!

My list of things do after Build


And finally: Get a Hololens! But that one is going have to wait a bit. I think after doing all those things I’m a little bit less of a phony.

What is on your todo list? Anything I’ve missed or that you would love to learn? Please leave a comment!

Saturday, May 2, 2015

Have you seen the new dev/test labs on Azure?

One of the great scenarios for Azure is dev/test. Having the ability to quickly setup an environment in Azure and run your automatic or manual tests on them gives you an extreme flexibility. You pay per minute and you can have as many machines as you want in a couple of minutes.

But there are some challenges.

One thing I notice while working with customers is that they often want to limit how much money can be spent on Azure. Often customers asks for a cost calculation so they know beforehand how much Azure is going to cost them. Of course the whole idea of Azure is that you pay for what you use so giving of an exact amount is hard.

Another thing that teams sometimes struggle with is the amount of choice on Azure. You have different sizes of virtual machines, ranging from simple A-series to Godzilla machines. And add to that the number of virtyual machine images you can use, network settings and security configurations and a team can suddenly be overwhelmed with all the options they have.

Dev/Tests labs to the rescue!


During Build this week Claude Remillard announced a new Azure service: Dev/Test labs. You can now create one or multiple labs in your subscriptions. These labs can have a quota on how much can be spent. This means that a team can never go over the amount you configure, giving managers and others a nice and secure feeling.

But that’s not all. You can also configure which virtual machine sizes can be used, which templates are accessible and you can easily create custom base images for your team. The developer division at Microsoft uses this themselves. They have base images that contain stuff like the correct Windows version, Office and other standard tooling. Then each night they run a scheduled build that takes a base image, adds the newest version of Visual Studio to it and create a new image ready to go the next day. You can configure your lab to automatically shut down VMs at the end of the day to save on costs.

Now integrate this with the new Release Management service (a topic for another blog!) and you have a great new tool to automatically setup and break down environments on Azure.


Want to know more?


On Channel 9 you can find the recording of the session with demos showing the new lab features: http://channel9.msdn.com/Events/Build/2015/3-721. Currently this feature is in private preview but you can request to join: http://azure.microsoft.com/en-us/campaigns/devtest-lab/

I’ve requested to join the private preview. As soon as I’m up and running I'll post more details on this promising new feature.

What do you think? Is this useful? Anything you like to see? Please leave a comment!