Visual Studio 2008 RTM available on MSDN

As of this morning VS2008 Team Suite can be downloaded from the MSDN website

Downloading the bits right now…

Missing Feature in TFS Project Templates

While reading this post from Willy-Peter Schaub it crossed my mind that I forgot to post about a feature I think is missing in Team System Project Templates.

I recently tailored the Project Template from Conchango to serve as our ’standard approach’ for each Team Project we create. After some fiddling around I got everything the way we wanted except for the creation of a couple of folders in source control. Apparently there is no way of doing this automatically so we ended up doing this manually each and every time. Willy-Peter’s blog shows that we are not the only ones handling it this way. If you ask me, the Team System guys really missed out on this one…

Gotcha when launching DevEnv from Team Build Project

Ever found it frustrating that when you launch DevEnv.exe from a Team Build Project and something goes wrong you cannot determine what exactly messed everything up? Or that it makes your build hang because it probably popped up a dialog box after which you have to kill the build or stop the devenv process on the build server yourself?

Curse no more! While reading some old blog posts I ran into this one from Aaron Hallberg on ‘Building from the command line with DevEnv’ which for me didn’t include anything new but the one tip at the end of his post:

‘One other tip – you’ll typically want to specify either just “devenv” or “devenv.com”, rather than “devenv.exe”.  “devenv.exe” doesn’t generate any output, and will make debugging any issues pretty complicated.  Additionally, “devenv.exe” sometimes spawns GUI (e.g. to display the usage statement) which will hang Team Build, since it runs as a non-interactive NT service.’

Just plain stupid if you look at it afterwards J

WorkspaceMapping.xml and Continuous Integration

Here’s one that crossed my mind when writing my previous post. I was telling about the fact we configured our continuous integration build types to do Incremental Builds in order to optimize build time. While setting this up we noticed that nobody ever bothers to change the WorkspaceMapping.xml file to point to the actual source code needed to perform a build. Basically, a standard generated WorkspaceMapping.xml file points to the root of your Team Project like this:

<?xml version=”1.0″ encoding=”utf-8″?>
<SerializedWorkspace xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <Mappings>
    <InternalMapping ServerItem=”$/MyTeamProject” LocalItem=”C:\Workspace\” Type=”Map” />
  </Mappings>
</SerializedWorkspace>

I don’t know how you guys organize your Team Project source control folder but we do it like this:

$/MyTeamProject

    +-MyTeamProject

        +-Branches

            +-Oct06

                +-Documentation

                +-Source

            +-Apr07

                +-Documentation

                +-Source

        +-Releases

        +-Trunk

            +-Documentation

            +-Source

So for us, a default setup would get all artifacts (documentation, source code, released binaries, …) from source control to the workspace located on the build server. While in fact you probably only need the ‘Source’ folder beneath the ‘Trunk’ or maybe one of the branches. This way you are eating up a lot of disk space and bandwidth.

Sample based upon our largest project in TFS:

	Download Size
Complete Project	2 Gb
Trunk Only	400 Mb
Savings	1.6 Gb

Updating the WorkspaceMapping.xml file takes care of this:

<?xml version=”1.0″ encoding=”utf-8″?>
<SerializedWorkspace xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <Mappings>
    <InternalMapping ServerItem=”$/MyTeamProject/MyTeamProject/Trunk/Source” LocalItem=”C:\Workspace\” Type=”Map” />
  </Mappings>
</SerializedWorkspace>

A nice side effect of this is that the path everything gets downloaded to gets shorter and pointing to the solution file from the build project gets easier too.

The Big Picture

About us

We, meaning the .Net community within our company, are a very small part of the IT department of an international financial group with Belgian roots which is heavily investing in expansion towards Central Europe. The past years the group acquired banks, insurance companies, leasing companies … in several Central European countries. Since then most IT departments, formerly belonging to each acquired company itself, have been brought together under one management. We are now in the process of unifying the way we work and ultimately deliver software. As in most companies we also started outsourcing development but instead of working together with the usual suspects for off shore development, management decided to take over a company located in Chennai – India, virtually extending the local IT departments.

In an effort to standardize .Net usage for all IT departments within the group, we reorganized the Belgium based team into a service oriented structure. The picture below shows an overview of the different teams which make up our total .Net community. Bottom left you can see the .Net Service Center which basically manages methodology, toolset, framework, guidelines … This is the team I’m currently part of. The other teams, called Delivery Centers, actually take on real-life projects, each delivering software to their local customers while using the same guidelines, methodology, framework and centralized infrastructure.

Location			Team Size
Belgium	Head Office Leuven	Service Center	6
	Head Office Brussels/Leuven	Delivery Center	30
	Computer Centre Mechelen	Operations	n.a.
Czech Republic	Head Office Prague	Delivery Center	4
India	2 Office locations Chennai	Delivery Center	18

Table 1: Current Staffing .Net Teams

The infrastructure

All teams are connected to and collaborate using the infrastructure hosted by our operations department in Mechelen, Belgium. We’re currently using a single tier deployment of Team Foundation Server which is running on top of a virtualized Windows 2003 machine hosted on a Blade Server. Next to TFS we host a build server for the Service Center and one extra for each Delivery Center we add. The build servers are used for doing Continuous Integration builds and for building the MSI packages we need to deploy the software. The Load Test Environment enables load/performance/stress testing of both web and batch applications.

As you can see in the picture below every developer uses the Team Suite Edition of Visual Studio 2005. Project Leads and management can use the Visual Studio Team Explorer, Excel and Ms Project to connect to TFS …

Team members located in India access the Team Foundation Server thru a Team Foundation Proxy Server primaraly for reasons of limited bandwidth between our Computer Centre and the office in Chennai. I’ve been told bandwidth is still expensive in India .

Server		CPU	Memory	Disk Capacity
Team Foundation Server	Virtualized	Dual CPUUsing 4 cores of the Blade server	2 GB	Fixed – C: 10 GB Dynamic -D: 30 GB
Build Server	Virtualized	Single CPUUsing 2 cores of the Blade server	2 GB	Fixed – C: 10 GB Dynamic -D: 30 GB
Team Test Load Agent Server	Virtualized	Single CPUUsing 2 cores of the Blade Server	2 GB	Fixed – C: 10 GB Dynamic -D: 30 GB
TFS Proxy Server	Physical unit	Single CPU	2 GB	120 GB
Web Application Server	Virtualized	Single CPU	2 GB	Fixed – C: 10 GB Dynamic -D: 30 GB
Developer Machines	Physical unit	Dual Core CPU’s	2GB	120 GB

Table 2: Hardware specifications

That’s all for now, I’ll talk about TFS customization and the extra tools we developed ourselves in the next post.

About Software Factories

As you might know Belgium is a very small country and so we’ve got only one, truly Belgian, car constructor. They build one sole model, the Gillet Vertigo, of which they’ve sold about 25 in the past 12 years. Assembled by a rather small team of about 18 people each and every of these babies are beautiful examples of excellent craftsmanship. I think you can imagine that these cars are not destined to be owned by a mere mortal like you and me; we drive along in cheaper copies of a mainstream model and brand. E.g. Volkswagen spit out 5.243 million cars in 2005 (Group sales). I agree that probably both companies have a slightly different business plan. J My point however is that while it’s clear you cannot expect a work shop like Gillet’s to produce as much cars as e.g. Volkswagen, the difference in amount of employees is not the only factor. I can tell you scaling up in personnel and setting up extra work shops just won’t cut it. You’ll need a different toolset, new ways of having your personnel collaborate and you’ll have to automate as much as you can if you want to ramp up production, shorten time to market and cut in building costs while keeping the quality of your output within certain predictable and acceptable boundaries. If you’d want to express this approach using as little words as possible, you might consider using the word ‘industrialization’.

Gillet Vertigo

I hope Mr. Gillet won’t hold this against me but speaking in terms we all understand I think he’s a geek. I don’t mean this in a bad way. No matter the cost, this guy just wants to build stuff he’s passionate about without making any concessions whatsoever. If you’ll buy it, you’ll buy it, otherwise you don’t and that’s your loss. I can imagine that to him, what we call normal auto industry, is in fact the Evil Empire. If you make abstraction of the product we deliver, it isn’t hard at all to relate to Mr. Gillet isn’t it? Let’s face it, deep down, we’re all geeks… So maybe that’s why the process of industrializing software development makes some of us feel like turning over to the Dark Side.

For fifteen years I was part of small teams very much like Mr. Gillet’s little work shop, building beautiful software without ever thinking about turning over. The past two years however we’ve been very busy setting up our own Software Factory. Fear not, the Evil One has not yet gotten his hands upon us. Still faithful, we are. And the experience to me has been delightful because in fact, nothing changed. Instead of building software for business customers we’re now building software for development teams. We’re automating automation. So we’re still doing the stuff we are good at and passionate about. On top of that the result is that the development teams are able to ramp up software production. In 2005 we built 3 applications, after setting up the software factory in late 2005, our teams were able to deliver 14 applications in a one year time frame. Of course we ramped up headcount but the factory helped us streamline team output, shorten time to market and cut in building costs. If you want to read more about what constitutes a Software Factory according to Microsoft you can check it out here. Of course they focus on the usage of their tools and I admit I will talk about them too but keep in mind that merely having the toolset doesn’t mean you’ve got a Software Factory at all.

In next posts I will talk about our Software Factory and the different components we think are an inextricable part of it. Expect insights on toolset usage, infrastructural needs, methodology and organizational aspects you need to take into account when setting up your own.