Continuous Integration is the process which “run your project’s Code after someone change the code to the repository”, It also notifies all involved team if the build fails.

          Every time when somebody from the team change the code into the repository, a server (can be a script) check those commits and does a build of your code.

          A broken build should always be fixed immediately. A good CI process will help the team to move fast, with cleaner code and with a high level of confidence in the work they are doing.

An example:
Suppose developer A and B are both working on new features concurrently in modules X and Y, and both these modules depend on a third module Z. In order to complete their features both developers must make changes to module Z.

         Now, earlier both the developers are working separately by not committing their changes to the source control. Over a time, each of them would have copy of module Z which has very different code from each other. Now integrating both developers code with existing one will be a tough challenge.

The practice of continuous integration attempts to alleviate the cost of this integration step by having both developers commit to the main line frequently instead of leaving their changes in isolation, and also having both developers pull recent changes from the main line just as frequently. The effect of this practice is that a divergence in their shared dependency is found as soon as possible. This is beneficial as the sum effort to fix the individual conflicts is less than the effort to fix all conflicts at a later point in the future.

          Various Continuous integration tools used in market are Jenkins, TeamCity, Bamboo, Buildbot, TravisCI, Strider etc.