Voici un article incontournable de Martin Fowler sur le sujet: Continuous Integration

Résumé:

Practices of Continuous Integration

  • Maintain a Single Source Repository

    Although many teams use repositories a common mistake I see is that they don’t put everything in the repository. … everything you need to do a build should in there including: test scripts, properties files, database schema, install scripts, and third party libraries.

    The basic rule of thumb is that you should be able to walk up to the project with a virgin machine, do a checkout, and be able to fully build the system.

    Keep your use of branches to a minimum. In particular have a mainline: a single branch of the project currently under development.

  • Automate the Build

    Automated environments for builds are a common feature of systems. … Make sure you can build and launch your system using these scripts using a single command.

    A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment.

  • Make Your Build Self-Testing

    A good way to catch bugs more quickly and efficiently is to include automated tests in the build process.

    For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs. The tests need to be able to be kicked off from a simple command and to be self-checking. The result of running the test suite should indicate if any tests failed. For a build to be self-testing the failure of a test should cause the build to fail.

  • Everyone Commits Every Day

    The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts.

    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 the Mainline on an Integration Machine

    There are two main ways I’ve seen to ensure this: using a manual build or a continuous integration server.

    The manual build approach is the simplest one to describe. Essentially it’s a similar thing to the local build that a developer does before the commit into the repository. The developer goes to the integration machine, checks out the head of the mainline (which now houses his last commit) and kicks off the integration build. He keeps an eye on its progress, and if the build succeeds he’s done with his commit.

    A continuous integration server acts as a monitor to the repository. Every time a commit against the repository finishes the server automatically checks out the sources onto the integration machine, initiates a build, and notifies the committer of the result of the build. The committer isn’t done until she gets the notification – usually an email.

  • Keep the Build Fast

    Nothing sucks the blood of a CI activity more than a build that takes a long time.

    For most projects, however, the XP guideline of a ten minute build is perfectly within reason.

  • Test in a Clone of the Production Environment
  • Make it Easy for Anyone to Get the Latest Executable

    One of the most difficult parts of software development is making sure that you build the right software. We’ve found that it’s very hard to specify what you want in advance and be correct; people find it much easier to see something that’s not quite right and say how it needs to be changed. Agile development processes explicitly expect and take advantage of this part of human behavior.

    To help make this work, 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.

  • Everyone can see what’s happening
  • Automate Deployment
Advertisements