SQLServerCentral Editorial

A Cast of Thousands


SQL Code Deployments are hard work. The need for adequate tooling (schema and data comparison, source control, testing and so on) is well-established, in order to move code smoothly through the stages of dev, test, QA and into production. Discussed less often though is the equally formidable challenge of co-ordinating the skills, time and effort of the huge cast of people needed for a successful deployment.

In many ways, the process is akin to shepherding a film through the various stages of conception, filming and production. If people don't fully understand their role in the project, or interfere in issues beyond their remit, it can all end in frustratingly slow progress, spiralling project costs and even the infamous "on-set bust up". To help avoid such heartache, I offer a light-hearted guide to the role of each member of the cast in a typical SQL code deployment. So, without further ado, let’s set the scene and meet the crew.

Screenwriter = developer The SQL developer must craft the intricate design of the database application, from database schema to stored procedures, views and triggers. If the script stinks then so will the film, no matter how spectacular the hardware special effects (take special note, any Michael Bay-style producers). The screenwriter's work will be tinkered with many times before it makes it to the big screen

Actor = tester Testers, like actors rehearsing for the big performance, must explore the effectiveness of the script, suggesting tweaks and revisions, highlighting parts that just aren't compelling or amusing enough. Requires a subtle mix of classical training (automated test procedures and tools) with a touch of method acting (emotionally engaging with audience). There will be bloopers and blunders along the way, but unfortunately I've yet to hit upon a useful equivalent of the post-credits blooper reel.

Producer = project manager Using a subtle blend of Excel spread sheets, Gantt charts, post-it notes and mastery of a vast arsenal of cryptic terminology, project managers coax the project and staff through the deployment, on time, budget and schedule. They are relentless in their determination to hit target dates and schedule meetings, even if it means shredding the script, and leaving many actors' lines on the cutting room floor.

The Studio = Management Ahh…management, like the studio executives, they worry about the big picture... budgets, delivery, return on investment ...but sometimes take an unwanted interest in the finer details. They are made nervous by too many plot twists, and always hate downbeat or complex endings. If deadlines drift and expenditures rise too quickly they can pull the plug with impunity and without explanation, or demote you to a "straight to video" production.

Set builder = Server / Network Administrator Just as the rest of the film cast can't do much without the key grip, responsible for lighting and rigging on the film set, so a SQL deployment won't get far without the often-thankless work of the server and network administrators, providing everything from physical boxes and cables to virtual LANs and IPSec tunnels. And they better make the actors and screenwriters look really good.

Director = DBA Finally, I raise the curtain on the most important player in the whole production: the Director, who is, of course, the DBA. Conducting proceedings with pace, flair and style, the DBA coaxes the best performance from actors and scriptwriters, rallies the set builders, placates and diverts the management, and ensures project makes its way to production with as few hiccoughs as possible.

OK, I'm probably raising many eyebrows here; a wave of bias swept over me. Most DBAs aren't cut out to be Martin Scorsese, though it seems to me that an experienced and proactive DBA would be a viable candidate for the job. However, any DBA angling for the role should remember that if a film tanks everyone shoots the Director. If you produce a "Dr. Strangelove", you'll be a hero, but if you're responsible for a "Battlefield Earth", you may never work in that town again.


Rodney Landrum (Guest Editor)