Continuous integration (eng)
Upcoming SlideShare
Loading in...5
×
 

Continuous integration (eng)

on

  • 482 views

What is continuous integration? ...

What is continuous integration?
Building a feature with continuous integration
Practices of continuous integration
Benefits of continuous integration
Introducing continuous integration
Final thoughts
Continuous integration tools

Statistics

Views

Total Views
482
Views on SlideShare
482
Embed Views
0

Actions

Likes
1
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Continuous integration (eng) Continuous integration (eng) Presentation Transcript

    • Continuous Integration● What is continuous integration?● Building a feature with continuous integration● Practices of continuous integration● Benefits of continuous integration● Introducing continuous integration● Final thoughts● Continuous integration tools● Links
    • What is continuous integration?Continuous Integration is a softwaredevelopment practice where members of ateam integrate their work frequently, usuallyeach person integrates at least daily - leadingto multiple integrations per day. Eachintegration is verified by an automated build(including test) to detect integration errorsas quickly as possible. Many teams find that thisapproach leads to significantly reduced integrationproblems and allows a team to develop cohesivesoftware more rapidly. This presentation is a quickoverview of Continuous Integration summarizing thetechnique and its current usage.
    • What is continuous integration?● "it cant work (here)"● "doing it wont make much difference"● "yes we do that - how could you live without it?" The term Continuous Integration originated with the Extreme Programming development process, as one of its original twelve practices. Although Continuous Integration is a practice that requires no particular tooling to deploy, it is useful to use a Continuous Integration server.● Integration is a "pay me now or pay me more later" kind of activity.
    • ● Building a feature with continuous integration● Lets do something to a piece ● Update the working copy with of software,we assume its the changes from the others small and can be done in a & rebuild, check for clashes. few hours. ● It is yours responsibility to● Take a copy of the current create a successful build. integrated source onto your ● Commit your changes. local development machine. ● Build on the integration● Alter the production code, machine. and add or change the automated tests. ● Must fix the build quickly.● Build and run the automated ● Shared stable base, fewer tests. bugs, bugs show up quickly.
    • ● Practices of continuous integration● Maintain a Single ● Keep the Build Fast Source Repository ● Test in a Clone of the● Automate the Build Production● Make Your Build Self- Environment Testing ● Make it Easy for● Everyone Commits To Anyone to Get the the Mainline Every Day Latest Executable● Every Commit Should ● Everyone can see Build the Mainline on whats happening an Integration Machine ● Automate Deployment
    • Maintain a Single Source Repository● Software projects involve lots of files that need to be orchestrated together to build a product.● Tools to manage all this - called Source Code Management tools, configuration management, version control systems, repositories, etc.● Everything you need to do a build should be in there including: test scripts, properties files, database schema, install scripts, 3rd party libs.● Keep your use of branches to a minimum.● In general you should store in source control everything you need to build anything, but nothing that you actually build.
    • Automate the Build● Automated environments for builds are a common feature of systems (Make, Ant, Nant, MSBuild, etc.)● A common mistake is not to include everything in the automated build (virgin machine – up!)● Incremental builds, component builds, targets● Its essential to have a master build that is usable on a server and runnable from other scripts (Do not depend much on IDE)
    • Make Your Build Self-Testing● A program may run, but that doesnt mean it does the right thing.● A good way to catch bugs more quickly and efficiently is to include automated tests in the build process.● CI has a weaker requirement of self-testing code then TDD.● For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs.● The rise of TDD has popularized the XUnit family.● Tools that focus on more end-to-end testing, like FIT, Selenium, Sahi, Watir, FITnesse, etc.● You cant count on tests to find everything.
    • Everyone Commits To the Mainline Every Day● Integration is primarily about communication.● The one prerequisite for a developer committing to the mainline is that they can correctly build their code.● The key to fixing problems quickly is finding them quickly.● The fact that you build when you update your working copy means that you detect compilation conflicts as well as textual conflicts.● Since theres only a few hours of changes between commits, theres only so many places where the problem could be hiding. You can even use diff-debugging.● Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress.
    • Every Commit Should Build theMainline on an Integration Machine● Using daily commits, a team gets frequent tested builds.● People not doing an update and build before they commit, environmental differences between developers machines and other issues – prevent mainlines healthy state.● Integration build succeeds should the commit be considered to be done – developers responsibility.● Use a manual build or a CI server.● Do not just make builds on a timed schedule.● If the mainline build fails, it needs to be fixed right away. Youre always developing on a known stable base.● Its not a bad thing for the mainline build to break. Fix fast!● Patience and steady application – develop a regular habit of working mainline builds.
    • Keep the Build Fast● The whole point of CI is to provide rapid feedback.● For most projects the XP guideline of a ten minute build is perfectly within reason.● Start working on setting up a staged build.● Build pipeline – multiple sequential builds.● Fast commit build is the build thats needed when someone commits to the mainline.● Secondary build which runs when it can – for example tests that involve external services such as a database, etc.
    • Test in a Clone of the Production Environment● The point of testing is to flush out, under controlled conditions, any problem that the system will have in production.● You want to set up your test environment to be as exact a mimic of your production environment as possible.● Its common to have a very artificial environment for the commit tests for speed, and use a production clone for secondary testing.● Use virtualization.
    • Make it Easy for Anyone to Get the Latest Executable● People find it much easier to see something thats not quite right and say how it needs to be changed.● Anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.● Well known place where people can find the latest executable. For the very latest you should put the latest executable to pass the commit tests (pretty stable).
    • Everyone can see whats happening● CI is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it.● Tray monitors, lights, lava lamps, toy rocket launchers, etc.● Use a tool with a web site for dashboard, reporting and extended information.● Wall calendar for a QA team to put red & green stickers indicating healthy & broken builds.
    • Automate Deployment● To do CI you need multiple environments, one to run commit tests, one or more to run secondary tests.● Use deployment scripts to move between environments● If you deploy into production one extra automated capability you should consider is automated rollback.● Rolling deployments in clustered environments.● Trial build to a subset of users.
    • Benefits of continuous integration ●● The greatest and most wide ranging benefit of CI is reduced risk.● At all times you know where you are, what works, what doesnt, the outstanding bugs you have in your system.● CI doesnt get rid of bugs, but it does make them dramatically easier to find and remove.● Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. Broken Windows syndrome.● If you have CI, it removes one of the biggest barriers to frequent deployment – between customers and development.
    • ● Introducing continuous integration● Theres no fixed recipe (your setup & team)● Get the build automated. Build the whole system with a single command. On-demand.● Introduce some automated testing into you build. Identify major areas. Start doing.● Try to speed up the commit build. Magic 10m.● Begin with Continuous Integration from the beginning for a new project.● Get some help.
    • ●Final thoughts● Continuous Integration has become a mainstream technique for software development.● Many teams using CI report that the advantages of CI well outweigh the disadvantages.● The effect of finding and fixing integration bugs early in the development process saves both time and money over the lifespan of a project.
    • Final thoughts● when unit tests fail or a bug emerges, developers might ● initial setup time revert the codebase back to a bug-free state, without wasting required time debugging ● well-developed● developers detect and fix integration problems continuously - test-suite required avoiding last-minute chaos at release dates to achieve automated testing● early warning of broken/incompatible code advantages● early warning of conflicting changes ● large-scale● immediate unit testing of all changes refactoring can be● constant availability of a "current" build for testing, demo, or troublesome due to continuously release purposes changing code● immediate feedback to developers on the quality, base functionality, or system-wide impact of code they are writing ● hardware costs● frequent code check-in pushes developers to create modular, for build less complex code machines can be● metrics generated from automated testing and CI focus significant developers on developing functional, quality code, and help develop momentum in a team
    • ● Continuous integration tools Most popular:● Apache Continuum — continuous integration server supporting Apache Maven and Apache Ant. Supports CVS, Subversion, Ant, Maven, and shell scripts● Hudson — MIT-licensed, written in Java, runs in servlet container, supports CVS, Subversion, Mercurial , Git, StarTeam, Clearcase, Ant, NAnt, Maven, and shell scripts● CruiseControl — Java-based framework for a continuous build process● CruiseControl.NET — .NET-based automated continuous integration server
    • Links● http://en.wikipedia.org/wiki/Continuous_integration● http://www.martinfowler.com/articles/continuousIntegration.html● http://www.extremeprogramming.org/rules/integrateoften.html● http://cruisecontrol.sourceforge.net/overview.html● http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson● http://continuum.apache.org/● http://www.wakaleo.com/books/continuous-integration-with-hudson-t● http://www.developer.com/open/article.php/3803646/The-Best-Contin● http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.htm