Continous Integration in nutshell means that you save your work, you push it to the document management system (SVN in your case), all test are run automatically (both unit, integration, functional, etc. tests) and the application is compiled and prepared for delivery (ie. ISO image is created). Continuous Integration is not the same with Continous Delivery. Delivery is still done in different moments. CI ensures the product could be delivered if needed, nothing more.

Whenever something goes wrong, the team gets a notification. Usually at that point all work is halted and all efforts are concentrated on making sure the product is in a stable way. No pushes and commits happen on the repository while the system is not green.

CI ensures that the product is always in a stable state and potentially can be delivered any time. Please note that stable does not mean feature complete. There may also be half-implemented features, but the system can be stable.

CI is usually associated with Agile methodologies, however I do not personally know the exact history of CI.

Continuous integration means: integrating the code into a product that actually runs and can be tested happens all the time, not (as was previously the case) as a separate activity late in the development lifecycle.

It requires the build process of the application to be completely automated, and an automated test suite, and a server that builds the current state of the code and runs the test suite on it. This should happen daily, or even after each code checkin.

The advantage is that there is immediate feedback about code changes that cause compilation errors (e.g. because the developer failed to check in all the changes or uses some component not present in the build system) or test case failures. This makes such errors much easier to fix, as you know which change caused them and the person responsible still has fresh memories of what they did.

Without CI, all these errors emerge together at the same time during the integration stage, which makes them extremely hard to fix.

You might have a certain style in development: You checkout, code, compile, check, curse, change, compile, cheer, commit. You only commit working code, perhaps even in a less granular fashion like at the end of you work day, or when a feature is complete.
You verify your dependencies whenever you import API libraries.

When you start coding together with others and when there are mutual dependencies it makes sense to adopt continuous integration. Simply because you cannot know the impact of changes to people that depend on your code, and you receive no signal every time you need to update your imports.

So when either of you make a change, both projects should be built and tested together, i.e. run against each other’s API, built and tested with the new library, etc. Such tests, your code and someone else’s, are called integration tests.

Why continuous? Because it is easier to delegate coordination of integration to a system that tests a clean build whenever there is a change in either code base than it is to organize all of that for a human. The system is able to scale.

There are two aspects to continuous integration.

1. The development source control strategy ensuring that developers are able to continually integrate their ongoing work with other developers stable code.
2. The automatic building and testing of source code triggered by a
   commit to the source control

Point 1 is critical. It is the move to make the merges that developers actually perform to be frequent, and small in nature that makes the merges much more likely to be successful.

Point 2 is the tools and framework that’s needed to allow point 1 to occur safely, quickly identifying merges that have failed by breaking existing code.

How useful is it?

Incredibly. As a developer working on a project it enables you to spend most of your time focusing on what you are doing, and not worry about the concurrent work from the rest of the team. When your current work is complete, you then publish your changes to the rest of the team and over the next few hours they all merge your changes into their current work.

Without it, developers are doing big bang merges. Typically taking several days of their work, and having to merge it with all the changes made by the rest of the team at one go. When a merge goes noticeably bad, the other developer will probably have moved onto other work, and be starting to forget the fine details to help unpick the merge mess. Even worse, without the continual building and testing, as long as the code compiles, merge bugs can appear in the code and will not be picked up until testing (or customers) find them.

CI is useful, when you have:

• Code compilation
• Actual set of tests
• Reports, that based on you source code(code coverage, violence of code standards, etc..)
• Routine that you do periodically, after code compiled successfully

List can be continued..