1 / 10

Agile Developer Series: Continuous Integration

Agile Developer Series: Continuous Integration. By John Boal http://TestDrivenDeveloper.com. 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?”

tivona
Download Presentation

Agile Developer Series: Continuous Integration

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Agile Developer Series: Continuous Integration By John Boal http://TestDrivenDeveloper.com

  2. 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

  3. 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

  4. 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)

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. Further Reading • For more information on CI see the following: • Martin Fowler on CI • http://www.martinfowler.com/articles/continuousIntegration.html • Ward Cunningham on CI • http://c2.com/cgi/wiki?ContinuousIntegration • Wikipedia • http://en.wikipedia.org/wiki/Continuous_Integration

More Related