agile developer series continuous integration
Skip this Video
Download Presentation
Agile Developer Series: Continuous Integration

Loading in 2 Seconds...

play fullscreen
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