Story: Wolf++ fixes the Deployment Process

Jul 9, 2009 • Julian Simpson

The last of the top three stories for the Giveaway was this one from Wolf++. Enjoy!

My last gig I was hired on to be the build guy. On my first day I sat
shotgun to their deployment process. The manual process was as
follows.

1. Logon to the 'build box'
2. Get latest
3. Open visual studio and compile the application
4. FTP the resulting app to a staging area on our production webserver
5. Put the website offline
6. Run any new SQL files against the production database (Hopefully
you guessed the execution order correctly)
7. Copy the app into place
8. Put website back online
9. Hope nothing had broken.

I had quite a task ahead of me. It turned out not only was I the buy
guy, I also had to manage the development and QA servers, help the QA
staff with even the smallest technical hurdles (including
demonstrating many times how to use FTP, etc), help developers with
source control, teach developers it works on my box is not an excuse,
etc. We had one big shared database with a number of different
applications that had no deployment schedule other than 'yesterday'
and as soon as it's ready. Quick fixes went straight to production!

The first thing I tackled was how to divine which SQL scripts were
needed with which application. I created a file in each project that
developers would list source control locations of the SQL DDL files
that needed to be executed. It was a simple run first to last
ordering. Along with this I created a tool to read and package the
files along with a script to execute the package against each
environment. This became a part of the automated build process.
Later I even created an editor with syntax highlighting, source
control integration, and validation to easily construct this file.

Since all the applications shared a single database (a flaw they were
going to fix someday), I finally convinced them to deploy all the
applications together. So any changes to the database would be tested
in all the apps at the same time. Builds would first be tested on the
QA server and only fully vetted builds went into production.

I brought in FinalBuilder which I used to construct build scripts and
implement continuous builds. Quick build break feedback is a must.

Prior to this job I never had to work on live websites. I can say for
certain now working on live websites ratchets up the pressure. The
desire to improve the build and deployment process correlates directly
to the desire to not break services a large global customer base use.