Decoupling development from deployment - rackerlabs/otter GitHub Wiki
Goals
Decouple development from deployments.
This has several facets:
- Allowing in-house development to continue during deployment cycles, instead of forcing it to happen in lockstep with Rackspace-specific deployments.
- Allow third party (non-Racker) development and making these developers first-class citizens.
- Facilitate more ops collaboration between Rackspace deployments.
- If possible, create an example for other Rackspace open source projects with similar requirements.
Why?
In otter, development currently halts while deployments are ongoing. Deployments always happen from master
, but we also want to deploy a consistent version across data centers. If deployments slow down, development grinds to a halt. This problem is exacerbated because otter orchestrates other services, so we're unusually likely to be dependent on a different service.
otter
is an open source project. Right now, that just means that the source is publicly available. We want to commit to being a proper open source citizen. This means opening up development to third parties.
Continuous deployment
Right now, otter deployments are manual. It'd be great if, one day, they were automated. It'd be even better if they were not just automated, but automatically and continuously performed. Context: lvh's PyCon 2011 talk. Some tech has moved since then (for example, Docker wasn't a thing), but the basic ideas are identical.
While desirable, continuous deployment should not block this proposal. We should keep it in mind, and make sure we don't paint ourselves into a corner where it becomes harder or impossible. One reason this is interesting
Suggested plan #1 (lvh)
Development
- Development always happens against
master
of the blessed repo. - All development happens through pull requests.
- All pull requests must be reviewed by someone with commit privileges who is not the author.
Importantly, development makes no distinction between Rackers and other contributors.
These constraints should be verified by some sort of CI; e.g. if someone merges without a review from someone with a commit bit, the commit should be backed out from.
Rackspace deployments
TODO, pending discussion re: deployment above