This points us to one of the most important health metrics on a software development project. How long does it take for you to get a new team member working productively on your project? If the answer is more than one day, you have a problem. Specifically, you don't have a proper build process in place.I am a convert. Back when I worked at SISCO, my boss there, Kevin had me implement a build process. This was a set of batch files that got the latest code from source control, built components, built applications, set version numbers, and built the installer. With this, we could run pieces of it to get a new developer up and running in a few hours, with most of the time spent installing Delphi and Team Coherence. Once the batch files were pulled from Team Coherence, you could run the batch files and have your environment ready for work in twenty minutes. This also made sure that each of the developers has an identical environment of up to date code. Running daily builds on the build server was a boon for testing and made sure that new code was added to source control.
When I went to ProMed, I implemented a similar system using a combination of batch files, nAnt and Cruise Control.net. This brought order to chaos as production software had previously been built on the head developer's machine and changes made there were in many cases not checked in to source control.
Now at Everglades Direct, I have implemented a similar system using nAnt. When we convert all the Delphi apps to .net I may convert the scripts to msbuild. When we add another developer, it will be trivial to get them up and running on a new machine once their base developer tools are installed.
I could never work without a build process again. That way lies madness.
No comments:
Post a Comment