Continuous deployment

From CitconWiki
Revision as of 22:07, 25 June 2010 by 203.167.202.226 (talk) (New page: =continuous deployment= what environment? Dev, QA, Perf, Staging, Production What frequency? Per release, iteration, weekly, nightly, every commit. Nigel talked about continuous deploy...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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.