Continuous Integration (CI)

Let's face the Continuous Integration the development practice that requires developers to integrate code into a shared repository at least once a day per developer. Each check-in is then verified by an automated build, allowing teams to detect problems early. The "continuous" has meaning of regular work, like that you can detect errors quickly, locate them more easily and remove.

Also, it is about verifying if the new code you just wrote broke or not the code that was already working, since the automated tests and other tasks (like syntax verification) are executed when integrating the code. You can't, however expect continuous Integration to get rid of bugs.

Another very important thing when talking about CI is that it needs to be supported by a suite of automated tests (not only unit tests, but also by integration tests, and even better, if possible, by end-to-end tests)

The best part is that continuous Integration is cheap. Not integrating continuously is expensive. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous integration is composed of some essential tasks as Matthew Setter talks about it. you can look them up, but I would like to have a look at the most critical one's.

Make your build self-testing

A self-testing process is the kernel of continuous integration. The build has tests that validate the software. No matter whether you use BDD (Behavior Driven Development), TDD (Test Driven Development), or any of the other xDD’s, testing needs to be front and center in the build process.

Automate the build

Automating the build builds on the fact that it is self-testing. You have the tests in place, now make sure they are run every time. This is a natural complement to software validation.

Make it transparent

The software’s tested before it’s deployed. The deployment happens the same way every time.

Test in a clone of the production environment

This highlights a challenge that has plagued web-based applications for some time. Speaking from personal experience, whether developers develop on Linux, use OSX, or Windows, they usually host on Linux. Even when we develop on the same platform, we may not consider library versions, the existence of extensions, or the extensions’ versions, which can cause problems. So many things can go wrong after the application’s deployed.

Make it easy for anyone to get the latest executable

No matter whether it’s a senior or junior developer, whether it’s a long-term employee or someone brand new to the company, getting a working build of the latest copy of the application or service should be child’s play.

CI is not just a development practice by itself, it has also meaning for being competitive in the market,. It is very good, if you can launch new features that matters for your users faster than your competitors, so you can have advantage and better time to market. Then, CI allows you also to do another very important task from these days, that is called continuous delivery.