Your SlideShare is downloading. ×
  • Like
 Continuous integration step by-step
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Continuous integration step by-step



  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Lessons Learned: Continuous integration step-by-step 30/06/10 7:16 PM Share Report Abuse Next Blog» Lessons Learned by Eric Ries MONDAY, DECEMBER 8, 2008 Subscribe via email Continuous integration step-by-step Enter your email address: Lets start with the basics: Martin Fowlers original article lays out the mechanics of how to set up a CI server and the essential rules to follow while doing it. In this post I want to talk about the nuts and Subscribe bolts of how to integrate continuous integration into your team, and or, add to Google Reader: how to use it to create two important feedback loops. First, a word about why continuous integration is so important. Integration risk is the term I use to describe the costs of having code Blog Archive sitting on some, but not all, developers machines. It happens ► 2010 (35) whenever youre writing code on your own machine, or you have a ► 2009 (88) team working on a branch. It also happens whenever you have code that is checked-in, but not yet deployed anywhere. The reason its a ▼ 2008 (59) risk is that, until you integrate, you dont know if the code is going ▼ December (6) to work. Maybe two different developers made changes to the same Assessing fit with the Wisdom underlying subsystem, but in incompatible ways. Maybe operations of Crowds has changed the OS configuration in production in a way that is Engagement loops: beyond incompatible with some developers change. viral Continuous integration step- In many traditional software organizations, branches can be by-step extremely long-lived, and integrations can take weeks or months. Heres how Fowler describes it: The hackers lament Getting started with split- I vividly remember one of my first sightings of a large software testing project. I was taking a summer internship at a large English The four kinds of work, and electronics company. My manager, part of the QA group, gave me a tour of a site and we entered a huge depressing how to get them done: ... warehouse stacked full with cubes. I was told that this project ► November (14) had been in development for a couple of years and was currently integrating, and had been integrating for several ► October (10) months. My guide told me that nobody really knew how long it ► September (27) would take to finish integrating. ► August (2) For those of you with some background in lean manufacturing, you may notice that integration risk sounds a lot like work-in-progress Labels inventory. I think they are the same thing. Whenever you have code agile (8) that is un-deployed or un-integrated, its helpful to think of it as a huge stack of not-yet-installed parts in a widget factory. The more audio (3) code, the bigger the pile. Continuous integration is a technique for case study (2) reducing those piles of code. continuous deployment (10) Step 1: get a continuous integration server. customer development (11) If youve never practiced CI before, let me describe what it looks engagement (3) like briefly. Whenever you check-in code to your source control Page 1 of 4
  • 2. Lessons Learned: Continuous integration step-by-step 30/06/10 7:16 PM engagement (3) like briefly. Whenever you check-in code to your source control events (35) repository, an automated server notices, and kicks off a complete "build and test" cycle. It runs all the automated tests youve written, five whys root cause analysis (6) and keeps track of the results. Generally, if all tests pass, its happy hiring (5) (a green build) and if any tests fail, it will notify you by email. Most iPhone (3) CI servers also maintain a waterfall display that shows a timeline of every past build. (To see what this looks like, take a look at the CI lean startup (12) server BuildBots own waterfall). listening to customers (10) minimum viable product (4) Continuous integration works to reduce integration risk by encouraging all developers to check in early and often. Ideally, product development (19) theyll do it ever day or even multiple times per day. Thats the first recommended reading (5) key feedback loop of continuous integration: each developer gets search engine marketing (5) rapid feedback about the quality of their code. As they introduce more bugs, they have slower integrations, which signals to them (and slides (11) others) that they need help. As they get better, they can go faster. sllconf (10) In order for that to work, the CI process has to be seamless, fast, split-test (5) and reliable. As with many lean startup practices, its getting started thats the hard part. startup visa (7) Test-driven development (8) Step 2: start with just one test. video (8) You may already have some unit or acceptance tests that get run occaisionally. Dont use those, at least not right away. The reason is virtual goods (2) that if your tests are only being run by some people or in some situations, they probably are not very reliable. Startng with crappy About Lessons Learned tests will undermine the teams confidence in CI right from the start. Welcome to Lessons Learned by Instead, I recommend you set up a CI server like BuildBot, and then Eric Ries. Want to learn more about have it run just a single test. Pick something extremely simple, that me? Try About the author. Trying you are convinced could never fail (unless theres a real problem). As to learn more about lean startups? you gain confidence, you can start to add in additional tests, and See Four Myths about the Lean eventually make it part of your team-wide TDD practice. Startup or The lean startup. Get in touch: Step 3: integrate with your source control system. Twitter Most of the times Ive tried to introduce TDD, Ive run into this problem: some people write and run tests religiously, while others Email tend to ignore them. That means that when a test fails, its one of Facebook the testing evangelists who inevitably winds up investigating and Linkedin fixing it - even if the problem was caused by a testing skeptic. Thats counter-productive: the whole point of CI is to give each developer rapid feedback about the quality of their own work. So, to solve that problem, add a commit hook to your source control Additional resources system, with this simple rule: nobody can check in code while the Startup Lessons Learned, build is red. This forces everyone to learn to pay attention to the All Seasons: Every post waterfall display, and makes a failed test automatically a big deal from the blog, in one 600+ for the whole team. At first, it can be frustrating, especially if there page PDF. are any intermittent or unreliable tests in the system. But you Startup Lessons Learned already started with just one test, right? season one: Every post from the blogs first year The astute among you may have noticed that, since you cant check in print form. in when the build is red, you cant actually fix a failing test. There Startup Lessons Learned for are two ways to modify the commit hook to solve that problem. The Kindle first, which we adopted at IMVU, was to allow any developer to add a structured phrase to their check-in comment that would override Startup Lessons Learned - the conference. April 23, 2010 in San Page 2 of 4
  • 3. Lessons Learned: Continuous integration step-by-step 30/06/10 7:16 PM a structured phrase to their check-in comment that would override the commit hook (we used the very creative "fixing buildbot"). conference. April 23, 2010 in San Because commits are mailed out to the whole team, anyone who was Francisco. using this for nefarious purposes would be embarrassed. The Lean Startup Wiki - including a alternative is to insist that the build be fixed on the CI server itself. complete list of local meetups In that case, youd allow only the CI account to check in during a red and meetup organizers. build. Lean Startup Circle - a mailing list of dedicated and helpful Either way, attaching consequences to the status of the build makes entrepreneurs. Bring your it easier to get everyone on the team to adopt it at once. Naturally, questions. you should not just impose this rule from on high; you have to get the team to buy-in to trying it. Once its in place, it provides an FeedBurner FeedCount important natural feedback loop, slowing the team down when there are problems caused by integration risk. This provides the space necessary to get to the root cause of the problem. It becomes literally impossible for someone to ignore the failures and just keep @ericries on Twitter on working as normal. Terrible iPhone 4 bug today: gets stuck in an endless loop with As you get more comfortable with continuous integration, you can hotel wifi that redirects via SSL. take on more advanced tactics. For example, when tests fail, I Had to reboot. about an hour ago encourage you to get into the habit of running a five whys root-cause @zburt afraid not, but sounds analysis to take corrective action. And as the team grows, the clear- like a great event about 9 hours ago cut "no check-ins allowed" rule becomes too heavy-handed. At IMVU, we eventually built out a system that preserved the speed feedback, more updates... but had finer-grained effects on each persons productivity. Still, my experience working with startups has been that too much time spent Facebook Fans talking about advanced topics can lead to inaction. So dont sweat the details - jump in and start experimenting. Startup Lessons Learned on Facebook Like Startup Lessons Learned has 676 fans Like Be the first of your friends to like this. Randy Michelle Filipe Ben Labels: five whys root cause analysis, Test-driven development 2 comments: Edie Dina Kevin Kalimah Chris said... Recent & Upcoming Events Great article. Id also suggest looking at CruiseControl and Bamboo (by Atlassian). 2010 I am experimenting with using The one experience Ive come across with TDD is encouraging Plancast to track my 2010 event developers to add new (and good) tests. Starting with 1 test is schedule. Take a look and let me easy, but getting developers to write more with each new know what you think. feature (let alone on existing features) is a challenge. (The only successful way Ive seen this work is by having the 2009 show developer experience the awesomeness of unit testing on their own) Amazon The other experience Ive had is ensuring that test coverage doesnt drop off. When a test fails it is just as easy to Page 3 of 4
  • 4. Lessons Learned: Continuous integration step-by-step 30/06/10 7:16 PM doesnt drop off. When a test fails it is just as easy to comment it and do the "will fix this later" routine. (Note: I havent begun to ask about your experiences with "what is a good test?" and test coverage) Do you have any suggestions on these fronts? December 10, 2008 6:37 AM Anonymous said... My votes for using TeamCity as a CI server. March 26, 2010 8:42 AM Post a Comment Comment as: Select profile... Post Comment Preview Newer Post Home Older Post Subscribe to: Post Comments (Atom) Page 4 of 4