Code Integration
A software development team consists of a set of developers each working in their own development environments, containing tools to develop. Due to the different environments in which the code is getting built and the need to create a deployment version, there is a need to maintain an official environment and an official codebase for the application being developed. The process of integrating the code for changes developed in the local development environments into the official codebase and ensuring that the intended functionality changes are achieved in the integration testing environment, is the code integration we are referring to here. In the subsequent sections, we will look into some good practices around this.
Continuous Integration
Continuous Integration (CI) is a software development practice that allows developers to work as a team, where each team member integrates his work into a central repository, very frequently. This in turn results in multiple integrations taking place daily which presents an opportunity for correcting issues early on. In order to carry out an integration, the code is first verified, converted to a deployable state and deployed to the official stage for integration – the integration testing (IT) environment. Based on the technology involved, this might consist of performing compilation of codebase, post processing of build output etc. Once the changes are integrated and deployed to the IT environment, the product could be verified.
Why do we need Code integration
The main goal of CI is frequent verification and correction of errors when changes are introduced to the code base. This rapid feedback allows programmers to correct errors as soon as possible and we keep developing the official codebase, in small chunks ensuring things are fine at each integration.
How does Code Integration work?
There are quite a few tools in the market – both open source and licensed ones – which help in creating a CI environment for different technology stacks. In this section we will touch upon the different steps involved in creating a CI environment and types of tools that help us.
The first step involved in a continuous integration solution is a mechanism to integrate the code changes from the different developers into the official codebase. This can be addressed with the help of a source code control system. A developer checks-out a working copy of the projects’ source code from the central repository to start work. On completing the task at hand, the developer commits the code back to the repository. The source control system will have mechanisms and tools for tracking different versions of the code artifacts, identify conflicts and resolving conflicts between versions. Thus commits into the code repository after any such conflict resolution represents the individual changes being reflected in the project codebase.
The next main step is to trigger an integration based on the changes. Since a new integration makes sense only if there is a change to the codebase and since it involves consumption of resources, the trigger is usually based on a monitoring mechanism with the source control system to check whether there are any changes and a polling interval to control the number of integrations. CI tools are usually configurable to integrate with different source control systems.
As mentioned earlier, once an integration is triggered, based on the technology, there will be a series of steps that needs to be executed. The CI tools provide an infrastructure to specify the tasks to be performed. The tasks configured typically involves
Ø Labelling the codebase and fetching the current version of the codebase.
Ø Verification / Preparation of code for deployment like compilation
Ø Keep back-up of build.
Ø Deploy the build to the integrated testing server.
Ø Runs required tests.
Ø Generates reports like code metrics to measure the quality of the code
The impact of implementing CI and following it in the right spirit is that the development happens in an incremental fashion, with necessary sanity checks at each increment. As a result, there is always an official copy of software that is working quite robust, though it has not yet been subjected to rigorous system testing. Another advantage of the incremental development is that the issues arising out of each incremental integration will be manageable, as opposed to a big bang approach.
This post was aimed at providing an introduction to CI. For more information on the practices and implementation of Continuous Integration please check out our next posts.
Continuous Integration Team @ Software Associates
Tags: android application, aspnet, code integration, code metrices, continuous integration, development practice, iphone apps
This entry was posted
on Monday, May 10th, 2010 at 10:35 am and is filed under .NET, Android, best practices, iPhone, research.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.