The development of any application is divided into iterations and on the completion of the first iteration it takes several months to integrate our code into a product that could be passed to Quality Assurance. Unless integration is sensed and planned it can hinder to appeal the application development lifecycle. For this reason, it is important to use Continuous Integration tools to overcome this issue in your development lifecycle.
Popular open source Continuous Integration Java tools are:
- Hudson
- Jenkins
- CruiseControl
Commercial tools include:
- CruiseControl
- ThoughtWorks
- AnthillPro
- Jetbrains’ TeamCity
- Microsoft’s Team Foundation Server
Most of the tools of Continuous Integration in Java are pretty well established and provide similar services. These frameworks do not differ greatly, even the open source ones. You have many branches or concurrent versions of the source code that signify the completion of iterations, bug fixes, product releases but we need a consistent way to ensure that all integrations are in synch with one another.
A common feature among Continuous Integration tools is excellent support for software configuration management (SCM) tools. When you want to create a test environment or a virtualized system to run tests on, a plug-in will allow you to write code for that. Continuous Integration tools have plug-in systems that allow them to integrate with SCM tools as well as add functionality. Using such kind of integration frameworks also help in visualization of the release process, easy-to-read dashboards, tool integration (issue management, brief review, testing, etc.), and the ability to create a process workflow.
Key advantages of using Continuous Integration tools:
- It is a simple point of view that you will never find a magical solution to solve bugs from any software development, and this is why the principle of Continuous Integration tools comes in picture. It assumes that software will break. But, when used effectively, you find out about the breakage in smaller chunks.
- In terms of software quality, Continuous Integration tools can help you measure cyclomatic complexity, code duplication, dependencies and coding standards so that developers can proactively refactor code before a defect is introduced.
- The team spends so much time on fixing defects once the software is with the testing team - QA, integration testing, etc. Of course, it costs considerably more once it enters production. By implementing effective Continuous Integration practices, you can discover many of these defects as soon as they are introduced, which significantly decreases the cost of fixing each defect before going to production.
According to a survey approximately 27% of development teams across various organizations perform a daily build and less than 27% teams are using Continuous Integration tools. And less are implementing comprehensive automated developer tests and inspections as part of their Continuous Integration builds. With these practices, you completely script your build so that it can be run by a non-brainy process such as a Continuous Integration server and that it doesn't rely on an IDE or similar dependency.
Best Practices on how to achieve Continuous Integration
In a recent project our developers used one of the most popular Continuous Integration tools, Jenkins, to integrate the source code at a single central repository, SVN (Subversion). All the team members could easily access the full-fledge source code. Jenkins also acted like a user itself by sending notifications to all the team members in case of unstabilty in the functioning of test cases and checking the compilation process.
Jetbrains’ TeamCity has also been used in one of the current ongoing projects as build server. We often work with the following four environments:
- Development to verify commits in a server environment
- QA for testing purposes
- Staging for deployment checks and some UAT
- Production
Our developers use TeamCity framework to deploy at Development and to QA. Usually deployment to the Staging and Production are managed by the team members, and are therefore not automated. We instead used TeamCity framework to produce artifacts from the QA build. This saved a lot of time and the artifacts are the deployment kits sent for Staging/Production deployments.
In this way the Continuous Integration tools provide a complete control on which build can be promoted. It can be controlled on the SVN side with branches, and have different builds for those branches. You can therefore ensure what is getting deployed.
The bottom line is that Continuous Integration removes integration from being a significant phase of your development lifecycle and increases your confidence in applications. Ultimately a build is much more tedious than compilation while coding.