Support:Sumodev/Continuous Deployment

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

By the end of 2011, Support Engineering wants to move from big releases to Continuous Deployment. There's lots to do to reach that goal.

Measurable Goals

A bugfix reaches production within 30 minutes of being checked in.

Q1 2011

[DONE] Get JavaScript tests running. [1]
- [MISSED] XUnit results from JS test suite.
[DONE] Stop using SVN. [2]
[DONE] Crontab in Git. [3]
- Now we just need to start using it.
[MISSED] Script deployment.

Q2 2011

[DONE] Get release cycle down to one week.
[DONE] Replace branches with flags.
[DONE] XUnit results from Qunit

Q3 2011

Update dev server from CI.
Break Selenium into deploy-blocking and environmental.
Run deploy-blocking Selenium after check-in/dev update.
Run QUnit on all major browsers.
Deploy with Chief (big red button!).

Q4 2011

Action Items

Testing

[ON TRACK] Expand unit test suite to cover front end and JavaScript.
Organize test suite into unit/functional/acceptance/etc.
Work with Web QA Automation to maximize automated coverage and combine results.
Automated performance tests.
- Aggregation and graphs.

Infrastructure

Define a secure, defensive, robust flow from source control to production.
- If someone steals James' laptop, breaks in, and commits an infinite loop, that change should not reach production.
Automate/one-button push process.

Release Planning

There is a qualitative difference between deciding which work to group into a release and when to fix small bugs when changes go live immediately. Our concept of planning will have to change.

[DONE] Push every week. (By end of Q2.)
Push every day.
Push several times per day.

Features

[DONE] Support feature flags.
[DONE] Support features per group or percentage.