Review – Professional Scrum with Team Foundation Server 2010

I can already hear the voices…”why are you reviewing a three years old book?” “It is on 2010, it is outdated!” and so on.

Instead – trust me – I would strongly suggest you to buy it, for a simple reason. All the features used and explained in this book are the same or very similar from 2010 on, as we are talking about essential, cornerstone features.
Moreover, the book covers the very needed concepts needed for Scrum, so it is very helpful when you have to introduce a team to it.
The authors (Steve Resnick – Architect at Courion Corporation, Michael de la Maza – Agile Coach and Investor, Aaron Bjork – Senior Program Manager at Microsoft) explain everything with a very good pace and the required level of detail: they go step-by-step in every required part of the Scrum methodology, and at the end you will find a dedicated chapter on Spikes and an appendix dedicated to the Scrum Assessment.
It is very handy to use as a quick reference, just grab the required chapter and you would get your answer.
I am going to use it with a new team to be inducted to Scrum, by keeping it on the table during the daily Scrum and every Meeting. I bet it is going to be helpful

How an automated release looks like – the InRelease side

Once you have an automatic build leveraging InRelease for its automatic deploy, the workflow is pretty easy and straightforward.
Let’s say we make a whatever edit to a file in our project:

We check it in, and we trigger a Continuous Integration build.


Nothing too fancy at the moment. But of course we have to use the InRelease Build Definition Template for using those features, so we are going to see some specific activities in the build log, targeted at this.

The next steps are extremely easy and straightforward: depending on the Release Settings someone designed as Approver should approve the deployment:

Once this person/team accomplished this task, that’s basically all The only missing piece would be approving the Release (again, based on its settings. So it could be avoided, if needed)


A very useful aid is the possibility of scheduling the transition (i.e.: QA to Prod) to a future time, in order to be compliant with whatever company policy you might have.

And this is really all

Work Item Queries Charts

In the latest sprint, Microsoft released a very nice feature for reporting purposes: Charts for Work Item Queries.
It is incredibly easy to use. You do not need anything but Team Foundation Service. You can click on the link while opening a WIQL query:

and creating a new Chart

Finished.

Unfortunately at the moment is just supports flat lists, but in the future it is going to support the two other WIQL resultsets. It is very handy, you can embed it into an email or whatever, and it comes working with no configuration. Well done team!

How an automated release looks like – the Team Foundation Build side

Well, when it comes to the Automated Release our beloved Team Foundation Build has not so much to do…apart from hers usual stuff, with a slightly different Build Process Template.
For enabling an Automated Release, you have to add a custom Template and create a Build Definition using it. You are going to find it into the InRelease installation folder (…\InCycle Software\InRelease\Bin).

You are going to notice that there is a dedicated InRelease section for its parameters. If Release Build is set to True you are going to deploy the build.
You can set a Release Target Stage – if needed. Leaving it blank will make it go through all the possible stages unless stopped - and a specific Configuration to Release – leveraging the same configurations you might use in the Configuration Manager.
Every component must be configured to Build with Application or Build Externally. A Build Independently component won’t work. This is a known limitation of InRelease.
And obviously, both Acceptance Step and Deployment Step of the very first stage of the associated release path must be Automated.
The main task it does is the Configuration File Tokenization. This feature, together with a specific syntax into the configuration files themselves (usually __VALUE__), makes a build-time transformation based on the target stage.

For achieving this, it is needed to install the Client Component of InRelease on the Build Server.
It is not something that hard or trivial – you can integrate these specific tasks into a pre-existing customized Build Template so you are going to get a single template if you need.
After that, the InRelease Release Service is invoked, and everything passes through that, with the related configurations and settings.

Your first InRelease Release

In  the previous posts we saw the main pieces of InRelease, so let’s see how they fit together!
You are going to create a new Release: it is based on a Template, and it has two essential information to fill: the Target Stage, which is basically “where to stop” and the build to use, which could be the latest or a selected one (or even a build on-the-run).

You should define the stages, if you didn’t. It is extremely easy, as it just explains who approves the stages and who is the owner. You can add automation (starting a build), if you need.

Releases are fully trackable, and you get a step-by-step progress sequence to check, with its logs.