Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOpsDays Seattle 2017 - Continuous Integration: A bittersweet story

DevOpsDays Seattle 2017 - Continuous Integration: A bittersweet story

This is the bittersweet story of Continuous Integration. CI is practice that we fell in love with, embraced and then never fully committed to. I’ll share with you the current state of CI, what we think we are doing when we say CI and what we are really doing in terms of CI. Then I’ll remind us all why we fell in love with CI in the first place and make some suggestions on how to get back to the good stuff.

Presented at DevOpsDays Seattle 2017.


April 27, 2017

More Decks by suziejprince

Other Decks in Technology


  1. DevOpsDays Seattle 2017 Head of Product for ThoughtWorks Products 12+

    years experience with agile, continuous integration and continuous delivery practices Tweeting @pm_suzie
  2. @pm_suzie – Jez Humble, continuousdelivery.com “ … I N C

    I D E V E LO P E R S I N T E G R AT E A L L T H E I R W O R K I N TO T R U N K ( A L S O K N OW N A S M A I N L I N E O R M A S T E R ) O N A R E G U L A R BA S I S ( AT L E A S T DA I LY ) . ”
  3. @pm_suzie DevOpsDays Seattle 2017 1996 Steve McConnell describes the "Daily

    Build and Smoke Test" technique 2000 Martin Fowler’s first published his comprehensive Continuous Integration article 2010 Book “Continuous Delivery” by Humble and Farley published Our story so far….. 1993 Grady Booch used the phrase “continuous integration” in Object-Oriented Analysis and Design with Applications 2007 Book “Continuous Integration” by Duvall published 2017 Wikipedia lists 15+ continuous integration Tools 2001 The first continuous integration server Cruise Control is released 2015 CI described as “most essential technical practice” in SAFe 1998 Continuous integration is cited as a core practice of Extreme Programming (XP) ❤
  4. @pm_suzie 3% 5% 6% 18% Daily 68% Daily Weekly Monthly

    Other Never http://stackoverflow.com/research/developer-survey-2016#work-checking-in-code How often do you check in or commit code?
  5. @pm_suzie 40% 20% 40% Practising Plans to practice No plans

    http://public.brighttalk.com/resource/core/88443/december_16_agile_in_the_enterprise_wholz_131607.pdf When did or will your organization begin to practice continuous integration?
  6. https://blog.snap-ci.com/blog/2016/07/26/continuous-delivery-integration-devops-research/ @pm_suzie What do people know about Continuous Integration? Do

    they practice Continuous Integration? How do they practice Continuous Integration? What tools do people use to practice Continuous Integration? How do people define Continuous Integration?
  7. https://blog.snap-ci.com/blog/2016/07/26/continuous-delivery-integration-devops-research/ @pm_suzie You commit some code, something picks it up

    and builds and makes sure it still builds I push the code to the master branch after it's been tested on the test branch. That in return triggers something and gets deployed …testing your code all the time. Executing the code that you write all the time, making sure the code doesn't go stale
  8. https://blog.snap-ci.com/blog/2016/07/26/continuous-delivery-integration-devops-research/ @pm_suzie We tend to do anywhere between 15 and

    50 branches in a push The most challenging thing is when you end up with a lot of features piled together in one commit Anytime a feature is finally complete then it get’s merged into master