Together with other Swedish ALM MVPs and colleagues at Solidify we’ve decided it’s time kick off a Swedish Microsoft ALM/DevOps meetup! We plan to meet about once a month to discuss the concepts and ideas in our field.

The first meeting is on October 25 at the Solidify office in Stockholm. We’re very happy to have Jose Rady Allende, program manager on the Microsoft VSTS team, join us online to talk about the Microsoft Team Service Agile Transformation story. We’ll also going to have a couple of lightning talks on some cool features in VSTS.

We’ve had the new extensibility on VSTS for some time now, including the ability to create dashboard widgets. With TFS 2015 update 2 the same extensibility became available to our on-premise TFS and with TFS 2015 update 3 we now also have support for custom dashboard widgets.

Give this we just released an update to the Countdown Widget which adds support for on-premise TFS installation, which has been a much asked for capability.

When releasing with Microsoft Release Manager “vNext” the linked builds don’t automatically get marked as retained forever. If you want to be able to re-deploy released builds you want to ensure the builds are not deleted by retention polices. It’s a good idea to let the release definition take care of this (at some point, perhaps in the release to production stage) and mark the released builds as retained.

Here’s a PowerShell script that gets the builds used in the release and set the “keep forever” flag on the builds:

You can use this from your release definition either by including the script in one of the build artifacts and reference it or using an in-line PowerShell script step:

Note: the script above works with an on-prem TFS (using default credentials), if you want to use it with VSTS you need to include an authentication header instead and pass a personal access token.

In my DevOps and Continuous Delivery presentations I’m always including a step in the build process where source files are updated with the current build number. This gives us an easy way to correlate the produced package to the build it came from, which is great for traceability.

Enough people have asked for the script so I feel I should post it here. It’s really nothing special, just a lightly customized version of the original sample script Andy Lewis wrote a long time ago. The sample comes from mine and Jakob’s book on Continuous Delivery so make sure to get a copy if you want more context.

The script will apply a version to the source files, for instance updating AssemblyInfo attributes like this:

Our script will also update the version number for database projects (DACPAC packages) and Android manifest files. It’s easy to extend the script to do the same for Wix projects (MSIs) or C++ (RC) files following the same principles.

All you need to do to add it to your source code repository and use a PowerShell build step to run the script. In our example you need to pass the build source directory and the build number to the task:

Just in time for the Connect(); event the new book I’ve been working on together with Jakob Ehn has been released. This book gives hands-on examples on how to implement a continuous delivery process using the latest Microsoft tools. It’s been great fun to have had the opportunity to work with all the new versions of the product and it’s really great to see how well the different tools fit together and help us build DevOps and continuous delivery solutions much quicker (and better!) than before. If you want to learn more about the new build, test and release management systems there should be a lot of useful content here.

IntroductionBuilding good software is challenging. Building high-quality software on a tight schedule can be close to impossible. Continuous Delivery is an agile and iterative technique that enables developers to deliver solid, working software in every iteration. Continuous Delivery practices help IT organizations reduce risk and potentially become as nimble, agile, and innovative as startups. Although not sufficient in itself, having a powerful set of tools that lets you implement practices such as Continuous Integration, deployment pipelines, and release management certainly will help you go a long way. With the Visual Studio 2015 ALM suite of tools there is now a very compelling offering that covers all areas when it comes to implementing Continuous Delivery. Also, as this book will show, these tools are open and extensible by nature, meaning that you don’t have to use every part of the suite if you don’t want to.

This Book

Explains the concepts of Continuous Delivery.

Shows how to implement a Continuous Delivery process usinga modern development platform based on Visual Studio 2015,Team Foundation Server, Visual Studio Online, and MicrosoftAzure.

Gives you practical guidance and ready-to-use recipes to help youbuild your own Continuous Delivery pipeline.

What You Will Learn

What Continuous Delivery is and how to use it to create bettersoftware more efficiently using Visual Studio 2015.

How to use Team Foundation Server 2015 and Visual StudioOnline to plan, design, and implement powerful and reliabledeployment pipelines.

Detailed step-by-step instructions for implementing ContinuousDelivery on a real project

This script works well as long as the build server has permission to read and update test plans. But in some environments (such as when running on a hosted build agent in VSO) we need to do an explicit authentication. The solution I’ve choosen is to simply pass in credentials to the script and do an authentication before using the TFS API.

The script now takes two optional parameters if you want to authenticate, username and password, and you can just pass them in from the build definition. You can use ether basic authentication and pass both or use the safer option and pass a Personal Access Token (PAT) in which case you only pass the PAT as the password.

Here’s an example where you go to manage your credentials in Visual Studio Online. First go to your profile:

From the Security tab you can either create a Personal Access Token:

Press Add to create an access token:

Copy the PAT (it cannot be retrieved later):

If you want to use basic authentication go to the Alternate authentication section and fill in the secondary username and password:

A while back I wrote a post about how we can create a build bagde in TFS just like some of the other CI server can. It was actually really simple but since it was a custom extension it needed to be deployed outside of TFS, which of course is a bit of a pain.

With TFS 2015 RC and the new build system I’m happy to see there is now a new feature that let’s you get a build badge automatically!

To get a build badge you just need to enable it on the build vNext build definition:

Note how nice the url to the badge is presented:

With this you can easily include the build badge in any web page. I really like the new Markdown support so I would include it in your wiki by simply point to in the badge url: