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)
Related posts:
- dbdeploy.net Agile Database deployment for Java and .NET (This post was...
Related posts brought to you by Yet Another Related Posts Plugin.
{ 2 comments… read them below or add one }
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.
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!