Press "Enter" to skip to content

Continuous integration (part 1)

What is continuous integration

Continuous integration (CI) is the practice of merging developer workspaces with a shared mainline several times a day. Its main aim is to prevent integration problems. CI was originally intended to be used in combination with automated unit tests written through the practices of Test driven development. Initially this was conceived of as running all unit tests and verifying they all passed before committing to the mainline. Later elaborations of the concept introduced build servers, which automatically run the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practiced by some teams outside the XP community. Nowadays many organisations have adopted CI without adopting all of XP.

http://en.wikipedia.org/wiki/Continuous_integration

The traditional approach to the development of complex software has been to separate the development process into phases of coding, testing and integration. The continuous integration principle is to basically code, test and integrate at the same time, so that at almost any point in time, you have a working product. In order to achieve this, you need to be able to automatically build your entire application, including running the unit and acceptance tests. Thus, tools such as Ant or Maven are the foundation for continuous integration.

Every commit should trigger the build and the unit tests. This build should be fast and take no more than a minute or two. This is because that the developer needs to be notified when anything was broken with the commit so he can be able to fix it as soon as possible. If the build will take 10 minutes, the developer will be working on something else and will need to switch back which will be more expensive.

What is not continuous integration

Continuous integration is not a nightly build or scheduled integration point. When the build is run only once a day, because of the long time run or any other reason, it will be really hard to find why the test are failing after 50 commits from 5 developers. Every developer need to know immediately that he broke the build. Continuous integration is not building your project from your IDE. If you are not able to automate the process, then it’s not continuous integration and in that case don’t do that. I don’t want to say not to write the tests, but you are not forcing the developers to run them.

Why to use continuous integration

Use CI to automate the build so the developers can spend the time coding rather than validating the consistency of the code. It’s ok to check your code, bud who will do that for 10 developers and what will be the price? Tests and all metrics are run against of clone of production environment, you are not testing developement environment with all possible debug messages. Again, this is faster to do it automatically than let the developer to switch the environment all the time and waiting for the result.

With Selenium Grid a web tests you can run the tests in more browsers than only the one the developer has on his working machine. Mostly there will be problem with the system than missing browser.

Advantages

  • when unit tests fail or a bug emerges, developers might revert the codebase to a bug-free state, without wasting time debugging
  • developers detect and fix integration problems continuously – avoiding last-minute chaos at release dates, (when everyone tries to check in their slightly incompatible versions)
  • early warning of broken/incompatible code
  • early warning of conflicting changes
  • immediate unit testing of all changes
  • constant availability of a “current” build for testing, demo, or release purposes
  • immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing
  • frequent code check-in pushes developers to create modular, less complex code
  • metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team

Disadvantages

  • initial setup time required
  • well-developed test-suite required to achieve automated testing advantages

Leave a Reply to Anonymous Cancel reply

Your email address will not be published. Required fields are marked *