Continuous integration

5,759 views
5,448 views

Published on

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,759
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide
  • Classical waterfall model. Doesn’t *really* exist in practice. All phases are necessary important pieces of the software development process.
  • Problem is that the longer you wait or the more you build up between phases, the more risk you take on.
  • In reality, you’ve always got a back arrow to all the previous steps. A poor design decision could come out in integration or test, forcing you to go back.
  • Key insights
  • Key insights
  • Key insights
  • Key insights
  • Key insights
  • Key insights
  • Continuous integration

    1. 1. Continuous IntegrationAdin ScannellCTO, Gridcentricadin@gridcentric.com
    2. 2. WHO AM I?• Adin Scannell – Co-founder & CTO, Gridcentric.• Systems and virtualization guy.• Responsible for technology vision • (and the most annoying bugs).• Email: adin@gridcentric.com
    3. 3. What’s continuous integration?
    4. 4. Classic “waterfall” 4
    5. 5. 5
    6. 6. %#@$! %#@$! %#@$!
    7. 7. Minimize time between phases(and “distance” between developers) Integrate continuously Test continuously
    8. 8. “Continuous Integration is a software development practicewhere members of a team integrate their work frequently,usually each person integrates at least daily - leading tomultiple integrations per day. Each integration is verified byan automated build (including test) to detect integrationerrors as quickly as possible. Many teams find that thisapproach leads to significantly reduced integration problemsand allows a team to develop cohesive software morerapidly.” - Martin Fowler
    9. 9. Continuous IntegrationDoes require Does not require• Source control • Constant releases• Automated builds • (i.e. continuous delivery)• Automated tests • No manual testing • “Operations/Infrastructure as code” • Agile, Scrum or Kanban
    10. 10. Source control
    11. 11. Commit early and often (develop incrementally)Branch (when necessary) for features, releases Perform integration across all branches
    12. 12. Source control tools• Distributed: git, hg, bzr, bitkeeper, etc.• “Classic”: cvs, svn, etc.• A good branching and tagging strategy is important.
    13. 13. Build automation
    14. 14. Build every commit, or as frequently as possibleHave a consistent and easily replicable environment Build all branches, or build from staging repos
    15. 15. Build tools• The one true tool: Make• Alternatives: Ant, mvn, scons• On Windows: Visual Studio platform or Cmake• Not a good build tool: your IDE
    16. 16. Test automation
    17. 17. Types: unit testing, component testing, coverage testing, system and integration testing, installation verification testing Purposes: smoke tests, regression tests, usability tests, performance tests, security tests, acceptance testsMethodologies: whitebox, blackbox, greybox
    18. 18. More tests are better, but figure out what you delivers the most value to you. When in doubt…..Great idea: gate your main branches with tests.
    19. 19. Test tools• Web: selenium• C/C++: check, cunit, cppunit• Python: pytest, nosetests• Ruby: cucumber, rspec• And lots more…• Test frameworks are like a$$holes…
    20. 20. Continuous integration
    21. 21. Ties together builds and tests Archives artifacts, test results, build logs, etc. Automates triggers, pipelinesAllows for gating of merges, staging of changes
    22. 22. Continuous integration tools• Jenkins (Hudson)• TravisCI• Cruise Control• TeamCity• Buildbot• Bamboo• Team Foundation Server• Gerrit (reviews)
    23. 23. WORKFLOW
    24. 24. OpenStack (& Gridcentric) CI Workflow 4) Jenkins builds and tests change 8) Jenkins pulls (triggered) from github, builds, Gerrit Jenkins tests and publishes 5) Jenkins updates changeset on Gerrit 3) Developer pushes 7) On approval 6) Another developer changeset to Gerrit Gerrit merges and reviews the changeset pushes to github github 1) Developer pulls from github 2) Developer writes and tests code
    25. 25. How does openstack help me?
    26. 26. OpenStack cloudOpenStack CI Workflow Test Test VM Test VM Test VM VM Test Build VM VM 4) Jenkins builds and Build tests change VM 8) Jenkins pulls (triggered) from github, builds, Gerrit Jenkins tests and publishes 5) Jenkins updates changeset on Gerrit 3) Developer pushes 7) On approval 6) Another developer changeset to Gerrit Gerrit merges and reviews the changeset pushes to github github 1) Developer pulls from github 2) Developer writes and tests code
    27. 27. Advanced continuous integration• Leverage OpenStack to provide infrastructure. • Build slaves, test slaves, infrastructure dependencies.• Structure continuous integration tests as: • Boot a base OpenStack image. • Provision software using tool like Puppet / Chef. • Run full tests.• The same standardize procedures can be used to stand up production environments.
    28. 28. Continuous delivery
    29. 29. Discussion questions• Where is continuous integration easiest? Hardest?• Which tests (unit/component/system) are critical?• What are the biggest wins from CI?• What are your favorite tools?• How do you set a release cadence?• How are larger features incorporated?

    ×