Mistakes were made by Selena Deckelmann
- Misc management
- Prepare for failure, Failure is an option (it will happen)
- Book: “Everything is Obvious”
- 2 examples (NZ and Scotland) of rats gnawing through cables and taking out country
- Document -> Test -> Verify
- Failure to Document
- Write Docs, Update Documentation, Make documentation a step with your written processes, assign some time to that step.
- Doc Tools: Graphic Designers, wikis, sphinx, diagrams – timelines – bug tracking – ordered todo lists
- Failure to test
- Verify success criteria – Write tests – test with buddy – have a plan
- testing frameworks, staging environment, repeatable shell scripts
- Failure to verify
- Have a plan for things going wrong – have staging environment – test rollback plan, not just implementation plan
- Tools – People, staging environment
- Failure to imagine
- share stories of failure – talk to people are different from yourself – act out implementation scenario
- Failure to Implement
- reflection ( post-mortem )
- Plan to do post-mortem, document the plan with numbered steps and a timeline – test plan & rollback plan – Identify point of no return
- During – screen sharing – chatroom – Voice – Headsets – Designated time-keeper
Scaling Openstack by James Blair and Monty Taylor
- 6 projects in openstack.
- collection of related repositories
- Most contributors paid to work on it by their companies
- number , quality and area or contributors varies
- 6 monthly releases – design summits – continuously open truck – dev on master – Monthly milestones – stable branches post release
- Vision – consistent tooling and process on all projects -> Consistent Product -> Multiplier effect.
- Minimize meta-development, Standard tools
- Gerrit – code review
- Jenkins – Testing (pre and post merge)
- Orchestra (bare metal deployment)
- Lanchpad, documentation servers, planet, repos
- Environment: Ubuntu, Everything in Python (pep8 standard, openstack.common ). virtualenv/pip
- Gated truck – ensure quality – auto tests – means devs always start from working code – keeps bad code out of tree – process same for everybody, transparent, automated.
- Gerrit – stand-alone patch review system – lots of integration hooks – lots of review categories
- SSI using openid for all of project sites
- Git review is implemented as git sub-command to submit things to gerrit. zero-config <- looks cute
- Vendors can have labs and tests and code can be automatically submitted and tested on it
