Agile developer series continuous integration
1 / 10

Agile Developer Series: Continuous Integration - PowerPoint PPT Presentation

  • Uploaded on

Agile Developer Series: Continuous Integration. By John Boal What is CI?. Continuous Integration [CI] Automating the build process Build the entire system each time any new code is checked in Run all the automated tests for each build What’s “continuous?”

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Agile Developer Series: Continuous Integration' - dalton-goff

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Agile developer series continuous integration

Agile Developer Series: Continuous Integration

By John Boal

What is ci
What is CI?

  • Continuous Integration [CI]

    • Automating the build process

    • Build the entire system each time any new code is checked in

    • Run all the automated tests for each build

  • What’s “continuous?”

    • Ideally – build it after EVERY check-in

    • Practically – for larger systems, every 1-2 hours

    • Or at least a couple of times a day

Why do we need ci
Why do we need CI?

  • Rapid Feedback – we know very soon once we have made a mistake

  • We can fix problems right away

  • This practice helps keep the software working all of the time, even while work is being done

  • Problems tend to be smaller

  • Fewer bugs, faster bug repair

How do we do ci
How do we do CI?

  • Automation is the best way we can be successful at agile software development

  • First - we need some tools to help us

    • Code Version Control System

      • Subversion, Team Foundation Server [TFS] and others

    • Automated Build System

      • Cruise Control, TFS, and others

    • Status indicators / Notifications to make problems visible right away

      • Email

      • Information radiators (public build status monitors)

The philosophy of ci
The Philosophy of CI

  • Keep the software working at all times.

    • It’s “working” when all automated tests pass.

  • Whole Team owns the code – no “mine/yours”

  • Build it as often as possible.

  • All code has automated tests.

    • This includes unit and acceptance tests at minimum

    • Other kinds of tests can be run if feasible

  • Keep check-ins very small and frequent

    • Change only a few files, every hour, 4 hours MAX

  • Sync with source repository often – 4-8x per day, and (MUST!) before every check-in

Testing is crucial
Testing is Crucial

  • All checked-in code must have tests.

  • YES that means UI code too.

    • There are techniques available to test UI in almost all cases – MVC, Selenium, UIA in .NET and others

  • This means bug fixes also…

    • Find a bug, write a test … Eliminate regressions!

    • Even for simple bugs – don’t just fix it, test it!

  • Tests must run fast – we’re waiting for results

  • Split out “slow” tests, refactor test code too

  • Fast feedback is the goal

An example scenario
An example scenario

  • Web site, web services and a back-end SQL database

  • ASP.NET UI and web services, written in C#

  • MS SQL Database with tables, views, SP’s etc

  • Development Environment: Visual Studio

  • Test framework: NUnit for all unit tests

  • Acceptance Tests:

    • FitNesse and NUnit/Selenium RC

  • Source Control: Subversion Server

  • Build system: Cruise Control.NET and nAnt

Ci for example scenario
CI for example scenario

  • Cruise Control.NET uses the Subversion repository to sync the source code

  • Each step is a separate CC.NET “project”

  • CC.NET builds the projects using NAnt scripts

  • CC.NET runs NUnit console app to drive all the unit (and other type) tests written with NUnit

  • CC.NET deploys binaries to local DB and web servers and test fixtures to FitNesse bin folders

  • CC.NET launches FitNesse server, then executes NUnit with Selenium RC to drive UI acceptance tests and automated FitNesse tests

  • A build failure or failing test fails the entire build

Summary of practices for ci
Summary of Practices for CI

  • Use a single source repository for everything

  • Automate the build and the deployment

  • Test everything – automatically

  • Check in changes frequently

  • Each check-in should kick off a new build

  • Build and test as fast as possible

    • build and test in parallel if possible

  • Maximize visibility for current build status

    • be as noisy as possible for broken builds…

  • Collective Code Ownership

    • We all own a build break… fix a broken build ASAP, no matter how it happened. A broken build is Priority 1

Further reading
Further Reading

  • For more information on CI see the following:

  • Martin Fowler on CI


  • Ward Cunningham on CI


  • Wikipedia