Continuous deployment

what environment? Dev, QA, Perf, Staging, Production What frequency? Per release, iteration, weekly, nightly, every commit.

Nigel talked about continuous deployment for his start-up. Inspired by Eric Ries IMVU.com

If tests pass, then it's deployed

Dev on main trunk, no merge conflicts.

Can have features turned off until ready to go.

Idea is bugs only occur once.

This is a startup, so getting code out fast is critical for market validation. If things break, write new test, fix code, and deploy again.

IMVU deploying 60 times a day! 60 devs.

Forward and backward patch for DB, test code works with both states.

Written in Catalyst (Ruby on Rails with Perl... MVC).

Model test (unit test) - so models are testable Integration tests (selenium)

Code modularity

IMVU ensures released (but turned off) features passes all tests with existing code. So when switched on, no surprises (Yay for feature flags!).

E.g. A/B testing, when features are turned on for only some users! Twitter, Google doing this.

Flickr deploy every 15 mins.

Tests test things that have actually broken.

Sounds risky, but when working well is a risk reduction model. When scared we slow down, release less, risk frequency goes down, but magnitude of something going wrong increases.

For db rollback scripts, should be tested, could be that forward migration does not drop old tables/data, and even new code writes transactions to both old and new tables.

Risk. Many coys already have some devs/dbas with root production access to fix bugs on production because they have no good process for releasing fixes quickly.

e.g. in a bank, directors could sign-off the process of continuous deployment, not each release as would likely be the case now.

Continuous deployment can be ok to a UAT environment... get comfortable with it, then go to production. But if not that far, then go for UAT at least.

Banks may hold off as they can't currently automate all the testing (

Delaying releasing does not increase chance of finding a bug, or a poorly written test... actually delays the inevitable.

Build up set of tests/mocks to test downstream and upstream systems you integrate with.

IMVU clustered tests that take so long... break them out and architect tests so you can cluster our long tests, e.g. for batch tasks and integration.

Can still deploy twice a day and still use a QA team.... zero defects is not a requirement, it is balanced with an agreed level of risk.

Continuous / frequent deployment is less about automated processes, but more about increasing the rate of feedback.

Nigel's start-up is http://www.getyourgameon.co.nz

-- I should point out that CD is not my idea, Eric Ries is widely credited with formalising it as part of a system called Customer Development which has a lot of mind share in the startup world right now. It's definitely worth checking out his blog for the posts on CD, from there you'll find presentations and a deeper analysis of how it works at IMVU and why it's a great idea - Nigel