Continuous deployment - Revision history

121.98.80.122 at 00:56, 14 September 2010

2010-09-14T00:56:20Z

Jtf: add explanation on how I recruited to Nigel to do most of the talking. Added a few more links at the header.

2010-06-28T18:53:02Z

add explanation on how I recruited to Nigel to do most of the talking. Added a few more links at the header.

Nigel.charman at 20:04, 26 June 2010

2010-06-26T20:04:39Z

121.73.88.159 at 11:50, 26 June 2010

2010-06-26T11:50:21Z

203.167.202.226 at 05:35, 26 June 2010

2010-06-26T05:35:23Z

203.167.202.226: 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...

2010-06-26T05:07:53Z

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...

New page

=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.

← Older revision		Revision as of 00:56, 14 September 2010
Line 1:		Line 1:
		+	'''Note:''' There's a recording of this session available at http://classnotfoundtechcasts.blogspot.com/2010/09/citcon-anz-2010-continuous-deployment.html
		+
	Jtf started by creating a grid and asking how often people release to their production environment:		Jtf started by creating a grid and asking how often people release to their production environment:

@@ Line 40: / Line 40: @@
-Risk.  Many coys have some devs/dbas with root production access to fix bugs on production because they have no good process for releasing fixes quickly.
+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.
-Continous 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.
+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 (

@@ Line 1: / Line 1: @@
 what environment?  Dev, QA, Perf, Staging, Production
 What frequency?  Per release, iteration, weekly, nightly, every commit.
@@ Line 61: / Line 59: @@
 Nigel's start-up is http://www.getyourgameon.co.nz

← Older revision		Revision as of 05:35, 26 June 2010
Line 39:		Line 39:
	When scared we slow down, release less, risk frequency goes down, but magnitude of something going wrong increases.		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 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.
		+
		+	Continous 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.

−	~~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~~.	+	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

@@ Line 1: / Line 1: @@
-what environment?  Dev, QA, Perf, Staging, Production
+Jtf started by creating a grid and asking how often people release to their production environment:
-Nigel talked about continuous deployment for his start-up.  Inspired by Eric Ries IMVU.com
+X-axis: what environment?  Dev, QA, Perf, Staging, Production <br/>
 If tests pass, then it's deployed