Jerry Dennany's Occasional Clue

Kirk Allen Evans has an excellent post on Change Control.  He points out that many software developers view change control as synonymous with Visual Source Safe, and leave things at that.  He's correct in that there's much more to Change Control than source code control, and that Rational's solutions are only useful for those few cash-rich shops that can afford it.

However, I part ways with Kirk's arguments when he begins wishing that VS.NET would tie all of this together. 

A common problem I've been observing recently is that just about every developer starts wishing that VS.NET will do everything perfectly, and that we'd never need another tool, ever.  In fact, I recently blogged about just such a situation.

Truth be told, I enjoy the choice that multiple vendors offer, and Microsoft has gone to some lengths to ensure that VS.NET is extremely extensible.

There are also several vendors that can accomplish much of what Kirk's asking for.  A case in point is that a VS.NET --> Perforce --> DevTrack combination enables an end to end VS.NET based solution, extending change control and bug tracking control using Perforce's SCC solution along with DevTrack's extensible defect and feature tracking solution.

Indeed, this combination of products goes a long way towards providing the very solutions that Kirk's asking for.

If you want even to go even cheaper, the open source projects CVS (or Subversion) and Bugzilla are also available.  It will take more work to make things 'end-to-end', but it can be accomplished.

If VS.NET doesn't do what you need, that doesn't necessarily mean that Microsoft needs to plug that gap.  There are several ISV's that will point out that the gaps left in VS.NET create opportunities for others. 

--

I often talk to people in small software shops who are violating some of the fundamental tenants of modern software development.  Today I'd like to visit a topic that everyone knows about, but few people practice properly.  And no, I'm not talking about flossing.

One of the golden rules of modern software development is that one should build all software on a dedicated build machine. 

Before you brush me off and tell me that this isn't important, let me set up a scenario.

If I hand you a Visual Source Safe database full of code, can you recreate the software project from just that database?

Ok, now, if you hand me your VSS database, (or if you are really smart, a better tool like Perforce or Vault), can I recreate your software? Many people think that once they check their code into source control, then that's all there is.

Let's take a closer look at this for a moment. Now I've got a bunch of raw code, but how do I turn that code into an executable?  I need compilers, of course.  A critical piece that many teams miss is that the build machine should be a controlled item, just like any piece of code.  Of course, you can't check in your build machine into source control, but you can come close:

A build machine should:

1.  Be well documented.  This includes Version of the Operating System, Service Pack level, HotFixes installed, Tools installed, along with any special installation instructions.

2.  Be easily reproducible.  Anyone on your development team should be able to take the documentation, the build machine, and any required installation media, and recreate that build machine on demand.  If you can't, then you don't know what exactly is in your product.

3.  Not contain a single piece of software not related to the build.  For example, just because your project uses crystal reports does not mean that you need crystal reports on the build machine.

4.  Be in an area that is controlled in its access, if at all possible.  If this is not possible, then you should control who may log onto the computer.

5.  Be under change control.  No change to the build machine should take place unless that change is documented and approved.

A build process should:

1.  Be reproducible.  You should be able to recreate any version of your product (even internal versions) at any time.

2.  Well documented.  This goes back to step one.  How can you recreate what you don't know how to do?

3.  Performed often.  Preferably daily.  More often than daily if you believe in the tenants of continuous integration.

4.  Automated to the greatest extent possible.  The less possibility for human error, the more likely you are to have a perfect reproduction of software.  Script, Script, Script!

A few things not to do:

1.  Never make the build computer a developer's workstation!

2.  Never do anything with the build computer except build that version of software.  I strongly suggest using a disk image tool such as Ghost to re-image after every build.  You don't get much more of a 'known state' than this.  This was actually very important in the VB6 / COM world.

Most modern development methodologies, including XP and the Microsoft Solutions Framework recommend that any software project be built daily on a dedicated build machine.  The daily build is often referred to as the 'heartbeat' of the project.  If the daily build isn't working, then your software project is in trouble.  You need to fix it, and fast.

--

I was a bit surprised reading Robert McLaw's recent complaints about his problems building deployment solutions for his software products.  As a tool vendor himself, he should realize that Visual Studio is not meant to be the be-all end-all in tools.  Sure, it offers an extremely rudimentary means of creating installer projects, but it isn't suitable for anything but the most basic of installations.  If you want a robust installer, purchase a robust tool for creating them.  (I see now that he's taking a look at a few solutions).

There is a reason that Wise and Installshield have a big market - installing software on computers has never been a simple task, and it is getting more and more complicated with every passing technology.  Think the GAC really makes things easier from a deployment perspective?  Then you probably haven't messed with things like publisher policy files.  Installations are by nature complicated beasts.  XCOPY need not apply.

---

There's been some recent speculation on win_tech_off_topic that Microsoft could be interested in Vault as a VSS replacement...  Interesting.  The thread also mentioned that Microsoft tried (and failed) to make their own VSS replacement.  I'd also heard about Microsoft's difficulties in replacing Source Safe, but it is interesting to see this story corroborated.