All the Perl that's Practical to Extract and Report

Automated Build Process

milardj on 2006-01-05T16:23:05

The company I work for now used to be a client of my previous employer. For whatever reason they decided to buy the source code and develop/support the product (a pharmacy claim adjudication system) on their own. The company is US based and they hired 11 of us (8 developers, 2 QA, and an architect) and set us up in an office in Canada.

The company is not a software development shop so the first year or so was ... interesting. CM (configuration management) for our product (dozens of applications written in C, C++, PB, perl, sqlplus, Java comprised of 12K+ files) was left in the hands of our overloaded QA team. This responsibility gradually became my responsibility (I lead a team responsible for GUI, server infrastructure, financial subsystem, and database loads).

Here was our process at the start of the year:

  • developer checks out/modifies/checks in source
  • developer fills out a paper 'code promotion form'
  • CM collects the forms and starts the build process
  • CM manually extracts the files from VM (Merant Version Manager) to Windows. Since VM is not task based and their labelling functionality is a joke (if you do a get based on label the app interogates *every* file in the repository to see if it has the specified label which can take up to 10 minutes per promotion form)
  • CM manually ftps the extracted source to our build area on Unix
  • CM determines if there are any database change dependencies if so migration scripts are manually applied to the dev database
  • CM kicks off the build script
  • CM ftp's the build to the QA staging area
  • CM manually composes a build notification e-mail
  • when QA is ready to apply the new build CM must apply any migration scripts to the QA database (and manually apply grants and create synonyms)

Depending on the stage of the release I was sometimes doing up to 5 builds a day at a loss of 2.5 to 5 hours of productivity a day. Keep in mind I was a hands on Team Lead - still developing for each release.

Our process now:

  • developer checks out/modifies/checks in source
  • developer fills out a web 'code promotion form'

That's it. Happy times are here again.

The goal for 2006 is to introduce automated smoke and regression tests into the process (at least for core components like our OLTP engine) and generate pretty graphs like the Pugs team has done ( - loads slowly).