Continuous Integration: a bittersweet love story by Suzie Prince
•Download as PPTX, PDF•
1 like•271 views
This document discusses continuous integration (CI), including its history and benefits. It provides definitions of CI from experts like Jez Humble, who define it as integrating work into a main branch on a regular daily basis. The document also discusses research showing that most developers commit code daily and many organizations are practicing CI. Finally, it discusses issues like "CI theatre" where teams aren't getting full benefits and provides tips for improving CI implementation, like committing more often, fully automating the process, and using trunk-based development.
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Viewers also liked
Viewers also liked (20)
Similar to Continuous Integration: a bittersweet love story by Suzie Prince
Similar to Continuous Integration: a bittersweet love story by Suzie Prince (20)
More from DevOpsDays Baltimore
More from DevOpsDays Baltimore (11)
Recently uploaded
Recently uploaded (20)
Continuous Integration: a bittersweet love story by Suzie Prince
- 1. DevOpsDays Baltimore 2017@pm_suzie CONTINUOUS INTEGRATION: A BITTERSWEET LOVE STORY
- 2. Head of Product for ThoughtWorks Products 10+ years experience with agile, continuous integration and continuous delivery practices Tweeting @pm_suzie
- 3. @pm_suzie over 20 years 4000 people 40 offices 14 countries
- 4. @pm_suzie
- 7. @pm_suzie
- 8. @pm_suzie – Jez Humble, continuousdelivery.com “ C I D E V E L O P E R S I N T E G R A T E A L L T H E I R W O R K I N T O T R U N K ( A L S O K N O W 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 B A S I S ( A T L E A S T D A I L Y ) . ”
- 18. @pm_suzie Why we fell in love with CI?
- 23. @pm_suzie 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 ❤️
- 24. @pm_suzie
- 25. @pm_suzie Daily 68% 18% 6% 5% 3% 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?
- 26. @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?
- 28. 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?
- 29. https://blog.snap-ci.com/blog/2016/07/26/continuous-delivery-integration-devops-research/ @pm_suzie
- 30. https://blog.snap-ci.com/blog/2016/07/26/continuous-delivery-integration-devops-research/ @pm_suzie
- 31. @pm_suzie
- 33. @pm_suzie
- 34. @pm_suzie Not getting the benefits of CI
- 36. @pm_suzie Not ready for Continuous Delivery or DevOps
- 37. @pm_suzie SAVE YOUR CI NOW! 3 HOT TIPS
- 42. @pm_suzie
- 43. @pm_suzie
Editor's Notes
- Hello My name is Suzie Prince. I am head of Products for Thoughtworks in the product division. We build tools for software development teams. I have been working in software development for over 10 years. All of my professional experience has been working with agile, continuous integration and continuous delivery. I’m a Brit but I live and work in the San Francisco Bay Area. If you want to catch me when I’m not in Baltimore you can tweet me at @pm_suzie
- For those of you not familiar with ThoughtWorks we are a group of passionate technologists. We provide software delivery, pioneering tools and consulting services across the globe. We are very diverse group with 4000 people, in 40 offices and across 14 countries. In addition to helping our customers deliver better software, we also like to push the industry to be better. <CLICK to transition> We write books, publish tech roadmaps and support open source tools. Our commitment to software excellence and improving the IT industry is at the heart of what we do. We created the first Continuous Integration server, Cruise Control. The first Continuous Delivery server with pipelines GoCD. We are the people behind Selenium. We also developed the concepts and practices that would become “Continuous Delivery” and the authors of “the CD book” were TWers at the time they wrote it. In fact Jez Humble worked with us in our product division when we were first building GoCD. Ok enough about me and ThoughtWorks. If anyone wants to chat more about what we do or our products. I’ll be in the here for most of the two days.
- Today I’m going to tell you a love story about how we (the software industry) fell in love with Continuous integration. I’ll start by define continuous integration (or CI) and sharing what I think is important about the definition. Then share the benefits CI or what I like to call “Why we fell in love with CI” Then we will take a look at our relationship status with CI Finally review what we have learned And I’m happy to take questions at the end
- To get started I’d like to know abit more about you all Who’s has heard of CI? Who is doing CI?
- Ok for those who didn’t know CI or need a review
- Ci is where software developers or engineers who write code integrate their changes in a source repository, build the combined software and test that it works. Generally we use a CI server to do this and the process requires that we have self testing code. It’s a feedback loop that helps us get better. That’s basically the process. Quickly reviewed. But there are principles and practices that are associated with the process too.
- Here is my favorite definition of the CI by Jez Humble “CI developers integrate all their work into trunk (also known as mainline or master) on a regular basis (at least daily).” includes two of fundamental principles of the practice.
- That is that we check into master on a daily basis For me these are very key elements to what makes continuous integration, continuous aka aka and integrated into master. But there are a bunch of other things that you need to do to be doing CI such as …..
- Everything you need to build the project is in source control. The basic rule of thumb is that you should be able to walk up to the project with a virgin machine, do a checkout, and be able to fully build the system.
- Building every commit once. Yes. You can’t skip commits and still be truly continuous.
- Automating your build can definitely help you be better / quicker / more efficient at CI
- The whole point of Continuous Integration is to provide rapid feedback. And we want this to be fast because it’s a feedback loop and feedback that doesn’t come quickly is usually hard to deal with and ineffective
- And of course you're going to need code that tests itself each time something is committed. For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs. The result of running the test suite should indicate if any tests failed. For a build to be self-testing the failure of a test should cause the build to fail.
- You also want to make failure visible Red lights Alerts Noise Buzzers You want to know when your build is broken so you can fix it
- And then you want to fix you failures immediately No checking in on broken builds No long red streaks Red should be followed by green
- But remember I think master and daily are two most important principles
- Ok so now we have reviewed what CI is and what it means to me. Let’s take a look at why we fell in love with it in the first place.
- An obvious one I’m sure and most like the reason that originally was a great driver for CI was to avoid merge conflicts. These are the issues you get when you try to integrate a lot of changes at once. Traditionally this would have taken a long time at the end of a project potentially delaying releases and causing lots of rework. CI allows this conflict to happen often so the conflict is small and manageable.
- The second benefit is fast feedback. Small changes frequently you get faster feedback, This is a key driver for CI, but also agile and our favorite CD. By doing things continuously you reduce assumptions. In the case of CI you are to assuming your code is going to work as expected. Instead of assuming you will actually confirm, quickly, that it works as expected and if it doesn’t you get to resolve that immediately.
- And by doing it immediately you reduce assumptions AND risks later on in the project. There are less likely to be unknowns later on if you get the hard stuff out the way quickly and often.
- Finally an often forgotten benefit of CI but one I think is as important as the other and particularly relevant to those of you working towards a DevOps culture is that you get collective ownership of the code, of the build server and of the product. There are no code silos. Everyone can frequently see and integrate with the code of others. They can all own the health of the build and the status of the product. In a world where DevOps culture is hot and people want to release frequently and often the benefits of CI grow and grow. For example with CI, you have an always the most recent features ready to deliver and your ability to refactor and have evolutionary architecture are enhanced. So that’s why we fell in love in CI. Let’s take a look at ur love story so far …
- Our love story started back in the 90s when we first meet CI. Then1998 CI is cited as a key practice in XP and 2001 the first CI servers are released. The love continues to grow in the 2000s as articles and books are published first chronicling CI and then CD. Finally up to today we see that all “agile” method including management and process heavy SAFe (Scaled Agile Framework) include CI as key dev practice. And there are many many CI tools in the market place. So looking at all that you think that our love would still be as sweet as it was in the beginning right? It should be sweet right? Well here’s come the bittersweet.
- Honestly our relationship with CI it’s pretty complicated. Let me tell you why.
- This is some data from a Stack Overflow dev survey where they asked about frequency of code commits or check ins. We can see that nearly 70% of people are checking in at least once a day. On the surface things look rosy. If we think about my favorite def we have the “daily” part down.
- But if we dig a bit deeper we can see that this is not necessarily the whole story. This is data from Gartner. They surveyed their customers - specifically those in Agile Enterprise organisations. These are the organizations that make the majority of software out there in the world. In those organisations, the one specifically embracing change, who want to move faster and be better, we see only about 40% practicing CI and 40% are most likely never going to do CI. That’s huge. So this love story is definitely different than the one that many of us have been telling ourselves. In fact when we dig a little deeper we will see that it is quite different than what we might think.
- The data I am about to share with you are the results my colleague and I learned when we scratched a bit deeper into the CI love story. We conducted a research study last year using contextual inquiry. Contextual inquiry or research is a methodology that uses a combined interview and observation approach. We set up calls, video chats, and in-person conversations with software engineers at varying organizations and with varying levels of expertise to understand how they worked, what their big pains were, and the nuances of their days.
- Goals of this work were to answer some questions we had about CI Primarily we wanted to * Identify what users know about continuous integration (CI) and continuous delivery practices and principles. Identify pain points around practicing continuous delivery on a daily basis. First I’d like to share some things about that last one - “How do people define Continuous Integration?”
- Here are some responses when we asked people to define CI. “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” As you can see these participants (and they represent the vast majority) were unable to comprehensively define CI in the way that I did at the beginning of the talk. Specifically they didn’t mention the two key things that I believe are fundamental to CI - commit to master on a daily basis. But come no you might say - they weren’t super precise and a bunch of people were definitely missing some of the key pieces but maybe it’s ok…? Surely even if I hadn’t had the textbook quote from Jez I wouldn’t have defined it precisely. And it’s true definitions mean nothing. It’s the doing that is important so regardless of whether they could define CI they might still be “doing CI”. Let’s look at what they said they were doing in terms of CI.
- Unfortunately this is no better…. And in fact many often specifically said they were practicing something that is clearly not continuous integration the way I defined it. “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” “We tend to do anywhere between 15 and 50 branches in a push” Of those who said they were using long-lived branches and not regularly checking into a master branch, 90% also said they were practicing continuous integration. We also heard a lot of “we have a CI server” and “we use x tool” when we asked “are you practicing CI?” In fact with the exception of just more than 10%, everyone using a CI tool said they were practicing CI. It also really does appears that the use of a CI server or tool is what people mean when they say we are practicing CI rather than specifically practicing the fundamentals of CI as we discussed before.
- Our love story really has taken a little turn for the worse. And it’s not quite as rosy as we’d think. We think everyone is doing CI. But lots of people still don’t really practice it. And those that do say they practice it Can’t define it Probably aren’t really doing it Yet probably are using a CI tool
- My colleagues I call this status “CI theatre”. It’s like playing at being software programmers - it’s close but not quite. Common examples of “CI theatre” include running CI against a shared mainline but with infrequent commits, so integration isn’t really continuous, running a build with poor test coverage, allowing the build to stay red for long periods, or running CI against feature branches, leading to continuous isolation. The resulting “CI theatre” usually makes people feel good, but is not a credible CI practice.
- So what? You might say. Who care’s if it’s complicated? What if many people practicing “CI theatre”. I’d like to take this opportunity to convince you why it’s important to care about CI and doing it “correctly”.
- If I am doing CI but not doing CI - I am not getting the benefits we started doing this all for in the first place. If I am are not checking in, working locally or working on a long lived branch then I’m not getting fast feedback, I’m not communicating my changes to the team, I’m not mitigating risks that I’ve misunderstood the architecture, or the requirements. I’m potentially wasting my time. I’m definitely not getting the full benefits from CI.
- Apart from that I’m likely to be experiencing pain that true CI would resolve. In our study it was very clear that not doing the the master and daily aspects of CI was painful to people. People who said they were doing CI also said they experienced anxiety when merging all their code to master, when they had to merge all their changes at once or explain a huge commit to the team. One participant described the horror of having worked in a branch, changed 100 files and 7000 lines of code, entered a code review and just being overwhelmed trying to explain it all to his colleagues. He said “I wish there was a nicer to decompose commits because it's hard to keep everything in your head.” The whole time I was screaming inside there is - it’s called “CI”.
- But really this is a heart of why I am mentioning this here. Why I came to this conference to talk about this topic. CI is fundamental for CD and DevOps CI is important to organizations who want to move more quickly. All these organizations who want to move quickly, be faster, disrupt, innovate, do CD and have a DevOps culture they need to embrace CI. And not just “do CI” or “CI theatre” but really understanding it and get back to the fundamentals.
- Ok so let’s assume that I’ve convinced you that CI is a fundamental practice that takes work and needs to be committed to. Where do you start to get your relationship with CI back on track? I have some tips!
- Back to basics. So if you are not doing CI this where you can get started and even if you are “doing CI” there is always remove to improve. I love the saying “Frequency reduces difficulty”. Why? Because in doing something more often, the task becomes smaller, making it easier to achieve. Continuous integration is a key example of something that becomes easier and easier the more often you do it. Continuous deployment is a similar example. So you can see how these things build on one another. So my advice: commit code to your repos more often and integrate branches to ‘master’ more often.
- Automate. This goes along side “frequency reduces difficultly.” People fear doing something often because it feels like more work so make your life easier and automate it. Automation is a cornerstone of strong continuous integration so if you you haven’t automated anything then start. And if you have automated start asking yourself “Why can’t this be automated?” every time anyone on the team does anything manually more than once. If it doesn’t help you do CI better it will definitely help you do CD better.
- Finally - trunk based development. This isn’t a talk about a trunk based development vs branch based development. But I can definitely tell you when we talked to people who had pain with their CI process it was those that didn’t practice trunk based development. That’s not to say trunk based is not hard. It is. But it brings the pain forward. Faster pain. Better results. I challenge you to consider doing trunk based development if you want to do better CI. If you can’t do that please please do short lived branches. No longer than day a day.
- Because master and daily, remember?
- That’s it. That’s our love story. We’ve taken a look at CI, reviewed what I think is important about the definition, reviewed the current state of the CI and how to get back to the sweet sweet fundamentals.
- So what is the end of our story…. I think how this love story is it up to you!?