MSBuildCommunityTasks and Versioning

Auto-versioning our assemblies in TeamCity using MSBuild was more fiddly than I expected but ultimately a very clean implementation.

I’m using TeamCity for continuous integration and MSBuild to run our project’s solution file (.sln) as the build script. I wanted each of our builds to have a version number on the assembly (.exe) so that testers would know what they were dealing with. The format for the version number is the familiar dotted quad of Major.Minor.Build.Revision where the Build would be the build number from TeamCity and the Revision would be our version control system (VCS) revision number (our VCS is Perforce).

I use Scrum for Agile software construction, in an OpenUP project management process, so I’ve decided our Major number is the number of the release to the customer and the Minor is the iteration (Sprint) that produced the build. For example, my first build with this system was 0.8.282.11066 which means: we’ve yet to make a release to the customer (0); the build was from the eighth two-week Sprint (8); TeamCity has completed 282 builds; and Perforce is up to revision 11066.

MSBuildCommunityTasks includes an AssemblyInfo task. These are the steps I used to get this working:
(1) added MSBuildCommunityTasks to our “ExternalTools” folder in Perforce and submitted the MSBuild.Community.Tasks.dll and MSBuild.Community.Tasks.Targets files.
(2) integrated the MSBuildCommunityTasks items from step 1 into the solution’s “tools” folder.
(3) updated the MSBuild.Community.Tasks.Targets file to the correct path to the MSBuildCommunityTasksLib (in our “tools” folder from step 2).
(4) imported the Targets file from step 3 into the project file (.csproj).

<MSBuildCommunityTasksTargets>..\tools\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets</MSBuildCommunityTasksTargets>
<Import Project="$(MSBuildCommunityTasksTargets)" />

(5) created the properties for the parts of the version number so it is easy to update for releases and works both on the developer’s machine, where the Build number and Revision number are set to 0, and on TeamCity which provides environment variables for the TeamCity build number and the VCS revision number.

  <PropertyGroup>
    <!-- Release -->
    <Major>0</Major>
    <!-- Iteration -->
    <Minor>9</Minor>
    <Build>0</Build>
    <Build Condition="'$(BUILD_NUMBER)' != ''">$(BUILD_NUMBER)</Build>
    <Revision>0</Revision>
    <Revision Condition="'$(BUILD_VCS_NUMBER)' != ''">$(BUILD_VCS_NUMBER)</Revision>
    <Version>$(Major).$(Minor).$(Build).$(Revision)</Version>
  </PropertyGroup>

(6) deleted the current AssemblyInfo.cs from the source and the VCS.
(6) add the AssemblyInfo task that will autogenerate the AssemblyInfo.cs for each build

  <Target Name="BeforeBuild">
     <AssemblyInfo CodeLanguage="CS" 
                OutputFile="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"
                AssemblyTitle="MyProduct"
                AssemblyDescription="My Product"
                AssemblyConfiguration=""
                AssemblyCompany="MyCompany Ltd"
                AssemblyProduct="MyProduct"
                AssemblyCopyright="Copyright © MyCompany Ltd 2009"
                AssemblyTrademark=""
                ComVisible="false"
                CLSCompliant="true"
                Guid="884276aa-6859-4318-8bb9-073f68a66057"
                AssemblyVersion="$(Version)" />
  </Target>

Now I need to create a WiX project to build a release version and expose it as an artifact in TeamCity so our testers can easily pick up a build themselves.

Technorati Tags: MSBuildCommunityTasks AssemblyInfo TeamCity MSBuild

When is a Task ‘Complete’?

In Agile you have to define when a task may be considered ‘Complete’.

‘Complete’ is when:

• the unit tests are all passing
• the automated acceptance tests are all passing
• the task’s user acceptance test is passed
• all supporting chores are completed, i.e. updating user guides, design documentation, etc..

If all the tasks are complete the workitem may be marked ‘Done’. The Product Owner should be marking ‘Accepted’ any workitem marked ‘Done’. He should be reviewing workitems daily if possible. If it cannot be accepted then he can throw it back into the iteration’s backlog.

Development Impediments

The environment at the place I’m currently working is structured to impede development. This can be divided into certain types:

(1) Quality of tools.

The workstations that the developers have are poorly specified for user interface development tasks. The machines are underpowered, resulting in frequent, long timeouts.

The machines cannot be easily upgraded as it is their CPUs that are too long in the tooth. A cost needs to be defined for upgrading machines and when there is the finance available this should be budgeted for. Unfortunately, the company are not big on setting budgets.

It is also difficult to obtain the necessary licences for software.

(2) Control of environment.

The lack of Local Admin rights on the developers’ machines significantly slows the uptake of new technology and the crippled web access severely limits access to information.

The workstation is the developer’s tool of the trade. Restricting the developers’ access to their toolboxes is preventing them from working well. Policies that have been made to prevent abuse of the company’s assets should be enforced through instructions and disciplinary action against offenders; there is no need to treat everyone as if they can’t be trusted to use a computer.

I cannot understate how important this issue is. A software engineer is an expert computer user and there’s no excuse for treating them as anything else.

(3) Specification of projects.

The current projects have no specifications. This means no realistic estimates can be made of when a project will be completed and how much effort will be required. A lot of effort is wasted as the work is developed ad hoc and often requires rework.

Requirements change is to be expected. Indeed, where it provides for a system better aligned with users needs they are to be welcomed. Management, however, must understand and accept the extra costs involved in rework or extra work.

(4) Distrust of developers.

There have been failings from the developers that have resulted, in the past, in misuse of company assets and timewasting. More recently there have been delays in project completion.

To help alleviate this mistrust the developers would like management to be regularly updated on progress. Attention will be drawn to project burndowns and management will be provided with regular demonstrations of the applications.

A company handbook would be useful to state the company’s policies.

Update (Jan 2010)
In the last six months I have made some small progress in clearing these impediments.

(1) The machines have been replaced, the last one today. A lack of planning, however, meant that upgrading a developer’s box, because he’d raised the performance of the old machine as an impediment multiple times, forced the old machine onto a new hire who then had to wait more than two months for his own upgrade.

We currently have developers working on different platforms, unfortunately, with a mix of Windows 7 and XP, and using different IDEs, VisualStudio 2008 and 2010, depending on what works for their environment. There is still no budget set for the purchase of licences.

(2) We have LocalAdmin rights on the boxes now. This has cut some tasks, like upgrading to a new machine, from one week to one day. To get this took raising the issue in almost every meeting with management for the last six months. Developers can now try out new tools and select the most appropriate tools for the job.

(3) Scrum has been implemented as the project management framework and, after a poor uptake, some training was arranged. Requirements are created as User Stories and estimates are made on the basis of Story Points and Velocity. It’s been made clear to management that any other estimates are inaccurate and the team will not be held to them.

(4) Inviting stakeholders to the Sprint Reviews has helped to partially dispel the distrust of the developers.

Management still look down on the developers, fail to understand their motivations and are incautious in revealing their attitudes towards them. Various attempts have been made by management to create some dialogue but most have been abandoned or have failed to appear after their initial announcement. As such, developers are unlikely to approach management when leadership it required.