Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
Traditional software development methods don’t dictate how frequently or regularly you integrate all of the source on a project. Programmers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts (and perhaps bugs) they are generating. Agile teams, because they are producing robust code each iteration, typically find that they are slowed down by the long diff-resolution and debugging sessions that often occur at the end of long integration cycles. The more programmers are sharing the code, the more problematic this is. For these reasons, agile teams often therefore choose to use Continuous Integration.
Continuous Integration (CI) involves producing a clean build of the system several times per day, usually with a tool like Cruise Control, which uses Ant and various source-control systems. Agile teams typically configure CI to include automated compilation, unit test execution, and source control integration.
Improving Software Quality and Reducing Risk, best practices of CI include:
Manage Source Code, Using a Version Control Product :-
The best way to manage source code is to use a version control product, which will provide a complete audit trail and history of the code. It’s also the place where the build server can monitor the code to determine any changes.
Version All Test Scripts and Configuration Files :-
Test groups and configuration files are similar to source code in that they change frequently and need to be audited and traced. They should be kept in the version control system. That way, teams can revert back anytime to previous versions of the code for comparison.
Enable Triggering of Builds from the Command Line :-
Teams should streamline the build process so that it uses common, standard tools. For example in the Java world standards to use would be Maven, ANT, NANT. To enable triggering of builds from the command line, teams should also standardize on a build script/tool and incorporate unit testing into the build process.
Commit frequently (at least once a day) as a Developer :-
Developers should commit frequently – at least once per day – several times a day is recommended. By doing so, developers will know the real time state and health of the software Integrate frequently; Build the Mainline on the Integration Server – Developers should integrate code changes frequently, so that integration doesn’t become such a hard process. Once teams begin doing this, they should have the continuous integration server building that main line.
Enable Fast Builds (Typically <10 minutes) :-
Builds should be fast. Anything beyond 10 minutes becomes a dysfunction in the process, because people won’t commit as frequently. Large builds can be broken into multiple jobs and executed in parallel.
Test Using a Replica of Production :-
Testing should be done in a production-like environment. The build server should be built to the same standards as production. Not necessarily in terms of being locked down and tightly regulated, but it needs to have the same version of operating system, patches, libraries, and so forth. That way, when the binary goes into production, there won’t be dependency issues.
Use a Central Binary Repository :-
A central artifact binary repository helps to manage and govern the binary artifacts and associated metadata. It also helps to enable end to end traceability by making it easier to associate binaries, builds and versions of source code.
Make it Easy to Obtain Build and Test Results :-
Build and test results should be easy to obtain since they are key to ensuring good quality. Developers should be able to easily see these results – especially when the build breaks. Developers should be notified as soon as possible as to why it broke, so that they can fix it as quickly as possible.
Automate Deployment :-
Automating deployment helps to reduce waste. Many continuous integration servers already have plugins for automating deployment to various web application servers like TomCat, JBoss, and WebSphere.
Using these best practices would definitely help for continuous deployment the overall benefits include:
Eradication of manual FTP deployment
Prevention & reduction of production & staging errors
Generation of analysis & reporting on the health of the code base
As the overall process matures CI helps in terms of business as well, the value of Continuous Integration reduces risk, reducing overheads across the development & deployment process, thus enhancing the reputation of the company by providing Quality Assurance!
