Joe Poon

Release early and often. On projects, we strive for small incremental changes deployed frequently to production. To achieve this, we do things such as:

• test-drive our code, build, check-in, repeat
• run continuous integration
• automate deployments

However, despite our best intentions, it all comes to a grinding halt if the business doesn’t want the code in production just yet.

Fear and Freeze
Often called a ‘code-freeze’, the reason for not deploying to production usually boils down to fear that the new code will introduce bugs and that any potential downtime is intolerable.

Delaying deployment out of fear causes problems and increases risk.

• End-users suffer: requested bug fixes/features are not seen for months.
• Ceremonious process: deployment to production becomes a “one-shot” deal.
• Golden window: developers, analysts and end-users feel the pressure to make this deployment perfect.
• Loss of focus: by the time deployment rolls around, developers may be working on other features or get pulled into other projects.
• Assumptions change: over time, requirements may change - your undeployed code is already obsolete. Or, perhaps the production infrastructure has changed.
• Loss ROI: why not capitalize on your software investment sooner and reap the value?
• Big bang: with infrequent deployments, the team will tend to adjust by accumulating code changes into larger deployments.

Deployment and the break fix
Ironically, after deployment to production finally occurs, if something goes awry, the business needs to fix it immediately. Usually this will be achieved by a last minute “break fix”, where the earlier qualms to deployment are temporarily forgotten. The business demands a quick code turnaround, the justification being that it is a “fixing a bug” and “not adding functionality.” It would make sense if this type of responsive mentality was the norm throughout the development cycle and not adopted only for emergencies.

Easing business qualms
As developers we take pride in iterative, well tested code and automated deployments. However, we also need to work with the business and understand why code can’t be pushed frequently into production, and minimize the delays where possible. Sure, there are applications where the nature is truly mission critical or it’s a legacy application where granular deployments are far from trivial. However, for all the other scenarios (which I suspect are the norm) where business fear is the driving force, we can work with the business to ease these qualms.

Quick and predictable
To do so, we need to demonstrate to the business that deployments to production can be a pleasant experience for both project managers and end users. Deployments should be:

• quick and predictable
• a graceful and seamless upgrade to the end user
• responsive and understanding to any errors/oversights that arise

The more frequently we deploy, the better we become at making it a good experience for the business.
In the end, if doesn’t matter if you can go from dev to staging in 60 seconds, if your code is left sitting in the garage.