Continuous deployment is a methodology whereby software code checked into a repository for a web application is automatically sent to the production server after all automated tests pass with no other human intervention. While not being an easy process to describe, it’s revolutionary in how it affects software development. The traditional software development process, even if agile, often involves bottlenecks around manual QA, a limited number of engineers empowered to push a release, and numerous issues when major changes are pushed.
Here are some thoughts on continuous deployment:
- Software releases go from big productions to non issues
- Small changes result in small issues and large changes result in large issues (bugs are inevitable, so keep them small)
- Automated testing becomes a critical part of the development process and no longer an after thought (there’s no right answer to how much code coverage is necessary other than it needs to be suitable to the product)
- New developers should push code to production on their first day, setting the tone for a culture that moves quickly and isn’t afraid to make mistakes
- Config flags are an important part of continuous deployment such that code that’s being worked on, but not ready to be seen by end users, is still pushed to production during development
Software-as-a-Service, whereby programs are delivered over the internet, makes continuous deployment possible (continuous deployment doesn’t work for installed software). With time, continuous deployment will become more prominent, especially when firms like Etsy espouse its benefits.
What else? What are your thoughts on continuous deployment in startups?
David Cummings on Startups 
Continuous deployment is certainly an interesting idea, but should be considered carefully. As I am working in the field of mission-critical systems, I know that small changes may result in large issues.
I would consider it for non-functional changes: in general, people do not like systems changing while using the system. You want to introduce these changes carefully, announce them, instruct users etcetera.
The upside is that a possible bug can be solved quickly too. So application of this technique needs a risk assessment: when the result is “low probability, low impact”, it would certainly an option.
Hi David,
Just wanted to add that in a (limited) way, continuous delivery does happen in desktop software too, just there is a delay between the release and the actual installation (e.g.: chrome’s auto updates, and we at Paessler do the same – http://www.paessler.com/support/faqs#crfaq)
The areas where CD is the most difficult are the various app stores, where part of the delivery (store approval) is beyond your control.
Just 2c, hope you find it useful!
Best,
Peter