Sticking plaster over a gaping wound

Post image for Sticking plaster over a gaping wound

by Julian Simpson on January 4, 2009

Another thing that I learned in 2008: the build manager can’t be responsible for ensuring the quality of the code that they build and deploy. We had QA’s but there were loads of little things to check: Were the release instructions accurate? Was there a rollback process? Did all the scripts actually work?

I did have some success in getting the obvious issues caught with a test. There were ongoing issues with file encodings until I had someone write a validator that could be run from a unit test framework. The same approach also managed to catch issues like incompatible database scripts.

All in all though, there was too much to do. We managed to get the checklist passed up to the developers and release managers. We won that battle. I lost the war.
(image taken from jluster’s photostream)

Share with the group:
  • Digg
  • del.icio.us
  • Facebook
  • DZone
  • LinkedIn
  • Slashdot
  • StumbleUpon

Related posts:

  1. dbdeploy.net Agile Database deployment for Java and .NET (This post...

Related posts brought to you by Yet Another Related Posts Plugin.

  • simpsonjulian
    That's what I thought, until I got there. Very strong bias towards pointy-click - both in software vendors (hello Bill!) and .NET developers. Dynamic languages very much underused. Also, large number of legacy applications with no easy deploy process. Eeeek!
  • I'm confused - wouldn't CI properly implemented catch all these problems? You should be deploying to a test environment just as to production, so running all the scripts. No instructions should be needed - all scripted; rollback can be tested too. Maybe there was resistance to testing in this way? I gather the tools were not as good as in the Java world.
blog comments powered by Disqus

Previous post: links for 2009-01-03

Next post: links for 2009-01-04