Continuous integration means that whenever a new version is pushed to the source code repository, the continuous integration server kicks in, pulls the code to its disk, and starts the build. It compiles the code first, then runs the unit tests, fires the static code analysis tools, and, if all goes right, it packages a snapshot release and deploys it on a development server.
CI servers have web interfaces that can be used to create a release. In such a case, the deployment can even go to the test servers or even to production depending on local business needs and on the policy that was created accordingly.
Automating the build and deployment process has the same advantages as any other automation: repeated tasks can be performed without manual intervention, which is tedious, boring, and, thus, error-prone if done by a human. The outstanding advantage is that if there is some error in the source code that can be discovered by the automated build process, it will be discovered. Novice developers say that it is cheaper and easier to build the code locally, which the developers do anyway, and then push the code to the server if the build process is already checked. It is partly true. Developers have to check that the code is of good quality and builds well, before sending it to the central repo. However, this cannot always be achieved. Some errors may not manifest on local environments.
It may so happen that one developer accidentally uses a newer version of Java than the one supported and uses a new feature of the new version. Enterprises do not generally use the latest technology. They tend to use versions that are proven, have many users, and are mature. This year, in 2017, when Java 9 is going to be released in July, huge enterprises still use Java 1.6 and 1.7. Since Java 9 has many new features that are not trivial to implement, I expect that the adoption of the technology may take even longer than the adoption of Java 1.8, which gave us functional programming and lambda.
It may also happen that a new library is added to the dependencies of the build and the developer who added it to the build file (pom.xml, or build.gradle) could use it without any problem on her local machine. It does not mean that the library is officially added to the project, and it may not be available in the central code repository (Artifactory, Nexus, or other implementations of the code repository). The library may have only been on the local repository of the developer, and she may have assumed that since the code compiles, the build is OK.
The CI server can run on a single machine or it can run on several machines. In case it serves many projects, it may be set up as a central server with many agents running on different machines. When some build process has to be started, the central server delegates this task to one of the agents. The agents may have different loads, running several different build processes, and may have different hardware configuration. The build process may have requirements regarding the speed of the processor or about the available memory. Some agent may run simpler builds for smaller projects but would fail to execute the build of a large project or of some small project that still has a huge memory requirement to execute some tests.
When a build fails, the build server sends out e-mails to the developers, and the person who sent the last update to the code repository is obligated to fix the bug without delay. This encourages the developers to commit frequently. The smaller the change, the fewer chances there are of a build problem. The build server web interface can be used to see the actual state of the projects, which project is failing to build, and which is just fine. If a build fails, there is a red sign in the line of the build, and if the build is OK, the sign is green.
Many times, these reports are continually displayed on some old machine using a huge display so that every developer or just anybody who enters the room can see the actual state of the builds. There is even special hardware that you can buy that has red, yellow, and green lamps to follow the state of the build and ring a bell when the build fails.