VERY LARGE DEVELOPMENT HOW TO RUN CODE REVIEW FOR 1000+ OPEN - PowerPoint PPT Presentation

VERY LARGE DEVELOPMENT HOW TO RUN CODE REVIEW FOR 1000+ OPEN SOURCE DEVELOPERS Joe Gordon

ABOUT ME Developer @ Full time upstream OpenStack Developer contact information jog0 on freenode github.com/jogo launchpad.net/~jogo

VERY LARGE DEVELOPMENT AS DEFINED BY OHLOH BY BLACK DUCK “ Very large, active development team Over the past twelve months, 1241 developers contributed new code to OpenStack. This is one of the largest open- source teams in the world, and is in the top 2% of all project teams on Ohloh . For this measurement, Ohloh considers only recent changes to the code. Over the entire history of the project, 1661 developers have contributed.”

WHAT IS ?

WHAT IS ? LARGEST OPEN SOURCE PROJECT? (THAT I KNOW OF) is 881,970 lines of python code and OpenStack is 968,893!

APIS

APIS

ARCHITECTURE

WHO IS OPENSTACK

DEPLOYMENT SCALE THE DATA CENTER (Rackspace data center)

DEVELOPMENT SCALE

BY THE NUMBERS

GRAPHS In January 2011 61 Contributors 71,181 lines of code

PROS AND CONS OF USING Pros fast to develop approachable language 'fun' Cons type checking other static analysis concurrency

DEVELOPMENT PROCESS

LIFE OF A GITHUB PATCH TODAY 1. Fork repo 2. Write code, test code and push to your github repo 3. Submit a pull request 4. travis-ci tests patch 5. Patch is reviewed 6. Patch is amended to address any negative comments 7. Code is merged 8. travis-ci runs on trunk

WHERE WE STARTED LAUNCHPAD (BZR AND ALL) (3 YEARS AGO)

REVIEW PROCESS EVOLUTION

GERRIT

GATE PEP8 + UNIT TESTS

GATE PEP8 + PY26, PY27, INTEGRATION TESTS

GATE + CHECK

CURRENT

LIFE OF AN OPENSTACK PATCH TODAY 1. Code is written and tested locally 2. Submitted for code review 3. Code is automatically tested on submission 4. Code is peer reviewed 5. Patch is amended to address any negative peer reviews 6. Code is approved (or rejected) 7. Code is re-tested as it will be merged 8. Code is merged

TODAY

PRINCIPLES Never break trunk Master branch is always green Developers are never blocked on broken trunk Transparency Automate everything Egalitarian Be Strict. Reduce burden on reviewers

TOOLS Work Flow Testing Integration Testing Communication

WORK FLOW Gerrit git-review Jenkins

TESTING tox testrepository Automated code quality checks: flake8+pep8+pyflakes+hacking

TESTING AUTOMATED CODE QUALITY CHECKS E1** indentation E2** white space E5** line length F401 module imported but unused F821 undefined name name H103 correct apache 2 license H30* import rules H301 docstring should not start with a space

INTEGRATION TESTING devstack zuul recheck elastic-recheck

INTEGRATION TESTING ELASTIC-RECHECK Measure integration tests in percent failure, not black and white Hard to debug transient failures - 10s of MB of logs Trivial to classify failures once have elastic search query

COMMUNICATION lauchpad etherpad pastebin irc mailing list

SUGGESTIONS FOR OTHER TOOLS?

OTHER WAYS WE MAKE DEVELOPMENT SCALE SHRINK PROJECT SCOPE OpenStack started with just two projects - Nova and Swift. Now the same functionality is spread out over 6 projects. Nova, Swift, Glance, Keystone, Cinder, Neutron

THANK YOU QUESTIONS? Statistics from ohlo.net Powered by reveal.js