Continuous Integration (CI) is not about tooling, it’s mainly about the way the team work, practices the team follows. CI follows the listed below practices, which help to keep application code integrated, tested, reduce time between bug introduction and fix, allow to follow the development progress by keeping application working through entire development phase:
- Maintain a Single Source Repository
- Automate the Build
- Make Your Build Self-Testing
- Everyone Commits To the Mainline Every Day
- Every Commit Should Build the Mainline on an Integration Machine
- Keep the Build Fast
- Test in a Clone of the Production Environment
- Make it Easy for Anyone to Get the Latest Executable
- Everyone can see what’s happening
- Automate Deployment
Tooling is there to ease following these practices. The idea of CI is perfectly summarised in the first paragraph of an article from Martin Fowler, the person, who introduced the term of CI
Interesting enough, this practice (pardon me for re-using the term) is not specific for Java development. I’ve been setting CI up for Java/JEE, C#/.NET, PHP and C projects. All had similar results – increase of knowledge sharing among the team members, improved confidence in code and overall quality of deliveries.
And what then? Then your code is ready to be automatically packaged and deployed to test servers, put through heavy suit of tests and delivered to production.