Continuous Integration Benefits

Continuous IntegrationNow that we have covered the Continuous Integration Concept, what are Continuous Integration benefits for using it in our projects(s) ?

Stable software application

By using continuous integration, software application are more stable. By stable, I meant, less bugs.

Continuous integration has many 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

Source: Wikipedia

Better software application integration during development

This is especially true in a team build, where different people are working on different features.

CI is a critical software engineering practice that promotes always having working code in the source code repository and enables a delivery team to embrace change and high agility by detecting problems early. CI is often coupled with a mainline model for source code versioning and configuration management which simplifies the management of code branches across multiple developers/teams.

  • Shorter Integration Feedback Loop – Bugs can be spotted sooner (within minutes instead of days) after code is checked in
  • Easier to find and fix problem code, or roll back changes – Amount of fresh code is small and easier to fix
  • A fully compiled and unit tested version of code is always available for deployment – Each successfully integrated build can be “baselined”
  • Shorter period of time between integrations makes next merge less painful – Simple integration issues are resolved before they become complex
  • Tighter Quality Control – maintain quality of entire code-base through continuous regression testing
  • Automates repetitive processes, reducing human error – common tasks such as packaging and configuration can be performed by automated scripts
  • Improves delivery speed – Reduced probability of indeterminate spike in effort at the end of the development cycle and integration effort is automatically factored into timeline of each feature
  • Enhanced Communication – integration issues arising from code change are revealed to entire team and automatic build reports are generated on a website and/or via email
  • Provides automated hooks for other quality practices – acts as a platform for automating other quality practices that can be run frequently such as code coverage, coding standard checks, document generation, regression tests, performance sanity tests, and continuous deployment

Source: Lean Agile Change

Software is always ready for demo by marketing team

I guess for your marketing department it is not important how CI works, but what CI means for new releases of your software.

CI will ideally mean that you can produce a new release of your software every day, ready to presented or sold to your customer, with small new features added. That does not mean you must deliver the new version every day, but you can if you want.

For example, if you have a new feature set planned to be officially released for the “2015”er version of your software, and you have parts of that feature set already coded and integrated today, the marketing guys can take the current version of your software and show it – more or less safely – at the next conference now in 2013. Without CI, they had to ask your team for an unplanned code freeze, every team member had to integrate the half-baked feature he is working on into the product, they might not have enough automatic tests ready, and guess what will happen at the conference – the “alpha version” of your 2015er release will have a much higher risk of crashing, especially when the new features are demonstrated.

Source: Doc Brown from StackExchange

From Martin Fowler, continuous integration benefits are:

On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk. My mind still floats back to that early software project I mentioned in my first paragraph. There they were at the end (they hoped) of a long project, yet with no real idea of how long it would be before they were done.

The trouble with deferred integration is that it’s very hard to predict how long it will take to do, and worse it’s very hard to see how far you are through the process. The result is that you are putting yourself into a complete blind spot right at one of tensest parts of a project – even if you’re one of the rare cases where you aren’t already late.

Continuous Integration completely finesses this problem. There’s no long integration, you completely eliminate the blind spot. At all times you know where you are, what works, what doesn’t, the outstanding bugs you have in your system.

Bugs – these are the nasty things that destroy confidence and mess up schedules and reputations. Bugs in deployed software make users angry with you. Bugs in work in progress get in your way, making it harder to get the rest of the software working correctly.

Continuous Integrations doesn’t get rid of bugs, but it does make them dramatically easier to find and remove. In this respect it’s rather like self-testing code. If you introduce a bug and detect it quickly it’s far easier to get rid of. Since you’ve only changed a small bit of the system, you don’t have far to look. Since that bit of the system is the bit you just worked with, it’s fresh in your memory – again making it easier to find the bug. You can also use diff debugging – comparing the current version of the system to an earlier one that didn’t have the bug.

Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. This is partly because you get bug interactions, where failures show as the result of multiple faults – making each fault harder to find. It’s also psychological – people have less energy to find and get rid of bugs when there are many of them – a phenomenon that the Pragmatic Programmers call the Broken Windows syndrome.

As a result projects with Continuous Integration tend to have dramatically less bugs, both in production and in process. However I should stress that the degree of this benefit is directly tied to how good your test suite is. You should find that it’s not too difficult to build a test suite that makes a noticeable difference. Usually, however, it takes a while before a team really gets to the low level of bugs that they have the potential to reach. Getting there means constantly working on and improving your tests.

If you have continuous integration, it removes one of the biggest barriers to frequent deployment. Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features, and generally become more collaborative in the development cycle. This helps break down the barriers between customers and development – barriers which I believe are the biggest barriers to successful software development.

Source: Martin Fowler

Continuous Integration benefits are real and the concept should be applied to all software application projects.