Continuous Deployment Discussion

From CitconWiki
Revision as of 08:55, 1 May 2009 by 24.1.235.136 (Talk) (New page: Here's a summary of the top ten indications that continuous deployment makes sense for your team: * To more quickly add value; get the code into the hands of users; remove inventory - inv...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Here's a summary of the top ten indications that continuous deployment makes sense for your team:

  • To more quickly add value; get the code into the hands of users; remove inventory - inventory is waste.
  • To elicit faster user feedback about defects, quality of the application, and value. Bugs should be fixed. Quality issues should be addressed immediately. Features that don’t add value should be dropped.
  • For rehearsal; practice shipping to production using the same automation used to ship to a staging environment. Remove bottlenecks through early identification.
  • The organization values happiness. How do people want to spend their time? Fighting fires and fixing production bugs isn’t fun. Why not spend the time up front to automate, rehearse, and avoid the “Last Mile Problem” that occurs when code piles up and before shipping? The organization must be willing and empowered to acknowledge and remove roadblocks.
  • The cost of a failed deployment isn’t catastrophic - manual review gates in between automated steps might be deemed necessary as a safety valve in order to catch errors that can’t be automatically detected in the test scripts. Automation reduces risk, though, so even apps with a high cost of failure can benefit from automation as long as there is an element of control and auditing.
  • Support costs of a new release are low. Companies don’t want to support hundreds of versions of a COTS product on store shelves, whereas a hosted web application effectively only has one live version at any given time.
  • The licensing / revenue model is compatible with frequent releases. Subscription models, free upgrades within a minor revision, etc.
  • The users cost of consumption is low, or users can opt to not upgrade. The previous point was about the cost of a deployment to the developing company. This point is about the cost, whether cognitive or financial, for consumers to make use of the new features as they roll out. An application that requires extensive training is obviously harder to continuously deploy than a chat avatar, for example.
  • There aren’t complex legal issues with deployment. A new feature might have regulatory implications. Perhaps SOX compliance must be proven before a feature can be released. Situations like this aren’t the norm, but they do happen.
  • The team is capable of excellence. One unreliable release will cost trust, user loyalty, and team morale. Too many unreliable releases will cost the product line and possibly the company. This is true regardless of whether or not automation used, obviously, but when we’re talking about continuous deployment with releases that can happen many times a day, we’re hopefully talking about feature releases, not just bug fixes. A solid development process that includes CI is a pre-requisite; I wouldn’t recommend continuous deployment to amateurs who haven’t yet written their first unit test.


I've posted more thoughts on my blog.