Continuous Integration is a process of continually integrating new changes with other peoples changes. The goal being to eliminate merge problems developing over time when many developers are changing the code independently in different directions.
It is fashionable in commercial environments to have a centralised source control with an automated build server with various testing and reporting metrics run on the code in response to a code change whilst allowing developers to work in a seperate branch whilst integrating other peoples completed changes but not sharing their changes till their work is complete - and to call that continuous integration.
However, i disagree. This kind of approach will allow developers working on sperate features both making large radical changes to avoid integration until the first developer finishes their feature. Whenb they merging their changes into the common branch they then dump the kind of merge hell onto their collegue that continuous integration is intended to avoid.
True continuous integration has developers commiting often (many times daily) to the same branch, ensuring that all code changes are integrated before significant divergence can occur.
As an approach, CI provides some advantages in reducing the impact that unexpected surprises at merge time can have, but creates problems else where in the business process of releasing and delivering software. (e.g. trying to develop new features whilst fixing bugs for the imminant release)
My advice is to avoid religious devotion to a methodology, but to implement processes that support your team and business environment that reflect how you work, how your business works around you and enables you to focus on software delivery and not process management.