Continuous Integration means that whenever a code is checked in it should :
1.)compile
2.)run unit test cases
3.) and create the build artifact.

In a project, many developers work on same files and if you don’t merge them daily or very frequently, chances are that it could become a huge task to merge the changes of each developer at a later stage. Moreover if something breaks it would be a nightmare to find out what went wrong.

By continuously integrating the code and compiling it we make sure that if something breaks it gets highlighted instantly and no new code comes on top of it until it is fixed.

This task of CI is handled by a dedicated server called as CI server which monitors the code base repository, and whenever there is a check-in , compilation, unit tests execution and creation of build is triggered.

If the build fails CI sends the email to all the stake holders including the person who has done the last commit. The idea is to fix the issue caused by this as early as possible so that nothing gets on top of it.

This eases out the task of finding which code has broken the build, and hence the developer can fix it quickly.

In this manner the product is virtually ready to be shipped after each commit,we might not actually ship it as the functionally could be incomplete, but it will be a running code.
After compilation all the Unit Test cases are executed, this is configured in the ant build script.

In our project we have used Jenkins CI server for automating this task of continuous integration.
Jenkins is installed as a standalone server and is configured to monitor the code repository, in our case, our GIT repo.

We have an ant build file configured to compile the code, run the unit test cases and make the build artifact (WAR/EAR).
We need to provide the path of this ant file to our Jenkins server to let it know from where to pick it.
Jenkins by itself is doing nothing, it is just triggering the execution of this build script.

Last configuration we need to do in Jenkins is provide the mail server settings, we need to provide the SMPT details with the email addresses to whom the notification mail has to be sent.

After this set up we are good to go. As soon as some new code is checked into Git repo, Jenkins triggers the build using ant build.xml which we provided, On success or failure it then sends a notification mail to the mail address provided.

we can do a lot of other configurations in Jenkins related to mails notifications and builds.
Instead of triggering the build on every commit we can configure it to make hourly builds.
Using Jenkins we can schedule regular database backup tasks.

We can also provide the path of server where the artifact needs to be deployed, and push the artifact to the server.
We can make build pipelines and design a workflow to deploy the built artifact, run acceptance test cases, etc..

Basically, we can make a script to all these tasks and the Jenkins server can trigger the execution of these scripts hence making the process automated.

Follow the blogs below on how to set up jenkins :

https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins
http://www.vogella.com/articles/Jenkins/article.html