Difference between revisions of "Continuous Integration procedure"

Revision as of 14:34, 2 September 2015

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." - Martin Fowler

Introduction

Continuous Integration is a well known procedure in software development that aims to reduce time to delivery software improving its quality. Continuous Integration consists in a set of practices and polices that should be enforced as widely as possible among the development team. The most important practices to follow are:

• keep source code in repository, preferably a Version Control System (e.g. CVS, SVN)
• automate builds on daily basis (or even more frequently).
• automated builds should include all source code (even database scripts!). The idea is that anyone can, standing in front of a virgin machine, check out source code from the repository, build it and have a running system on his machine
• builds are self-testing. Source code includes tests that are autmoatically executed at each build. Testing include not only unit-testing, but also functional and deployment testing for instance
• developers commit on mainline of source repository as frequent as possible, keeping the mainline builds successfully

Continuous Integration of gCube System

In next sections, most important best practices adopted in gCube System in order to speed-up software delivery and assure an high software quality are listed.

Source Code Repository

All gCube and gCore source code is maintained in centralized SVN Repository. Further details on this can be found in the section gCube Subversion Repository.

Self-testing code

JRA guidelines ask developers to provide one (or more) test-suites to test modules they develop. Provided test-suites are executed during Functional Testing

Automated Builds

Automatic builds of the entire gCube System software are scheduled on the Building Infrastructure on daily basis. Two versions of software are built:

• gCube Development Configuration (org.gcube.HEAD): the latest version of gCube source code is built to quickly reveal and fix integration problems
• gCube Release Candidate Configuration: if there is an ongoing Release Cycles or Maintenance Cycles, candidate configuration is built to solve all integration problems

Development Configurations

In ETICS, the org.gcube project each component has a "special" development configuration called: org.gcube.component-name.HEAD. This configuration points, at any time, to the latest source code available on the svn repository. From a practical point of view, this means that a valid *.HEAD configuration has the tag field pointing to svn repository's trunk and has not the revision number. Development configurations also exist for all subsystems and for the whole project. The latter is named org.gcube.HEAD.

Valid development configuration
 
 ETICS name:	org.gcube.annotation-management.abe.HEAD
 module name:	org.gcube.annotation-management.abe
 version:	1.1.0-0
 vcsroot:	http://svn.research-infrastructures.eu/public/d4science/gcube
 tag:	        trunk/annotation-management/Annotation_Back-End
 download from:	http://eticssoft.web.cern.ch/eticssoft/repository${projectName}/${moduleName}/[...]
 profiles:	
 created:	Thursday, April 24, 2008 1:10:36 PM
 modified:	Friday, May 8, 2009 1:29:46 PM
 id:	        99c1e2be-2872-4e91-93bf-ef1d14524520
 locked:	        false

Development configurations are expected to change very quickly (usually several times per day); also the API that each component exposes can change over time. The continuous build of these configurations is the usefulness of these builds, enabling developers to discover build problems difficult to spot on a local, unsynchronized environment.

Integration Configurations

When a Release Cycle or a Maintenance Cycle starts, components to be included in the upcoming version are released creating new ETICS configuration called integration configuration. The most remarkable difference with Development Configurations is the presence, in Integration Configurations, of the SVN revision number in the field tag that point at a specific commit in the SVN repository. This assure source code attached to configuration will not change during the time. Like Development Configurations, they also exists at component, subsystem and project level.

Sample Integration Configuration

  ETICS name: org.gcore.gcontainer.gcontainer.1.0.0-0 
 module name: org.gcore.gcontainer.gcontainer
     version: 1.0.0-0 
   * VCSROOT: http://svn.research-infrastructures.eu/public/d4science/gcube
         tag: trunk/PATH/TO/MY/COMPONENT@857 
* repository: http://eticssoft.web.cern.ch/eticssoft/repository
        path: ${projectName}/${moduleName}/${version}/${platformName}/${packageName}-${version}-${age}.tar.gz

Note: fields marked with '*' are common to all configurations of the same 
      module and cannot be overridden at configuration level

Build Activity

The main goal of Build Activity is to produce software artefacts from source code potentially spread across repositories maintained within the consortium. Resulting artefacts are the basis for subsequent activities of the release procedure such as testing, packaging and distribution to the user communities.

Building Activity aims at verifying that code compiles correctly and that components are integrated at API level. Building is done with the aid of the ETICS Command-Line tools that, by exploiting the model stored at the remote ETICS database, for each configuration automatically fetches the corresponding code and executes the specified build commands.

Building Activity takes as "parameter" the ETICS project configuration to build. Typically org.gcube.HEAD configuration is used for development builds, instead org.gcube.[VERSION_NUMEBR] is used for release cycle builds.

Builds are executed by a Build Server in the Building Infrastructure. When a build is scheduled, these are the steps executed on the build server that will perform the build:

1. source code is downloaded from D4Science-II code repository(ies) executing etics-checkout command;
2. some statistics on source files types are collected. Later on, they will be available in BTRT;
3. source code is built executing ( etics-build command);
4. artefacts, checkout and build logs, ETICS reports, plugin reports are published in the repository;
5. sa3-certification task is launched on the published build;

ETICS allows (if properly configurated) execution of a number of plugins during etics-build execution. Currently two plugins are executed during SA3 builds: checkstyle and findbugs. The former scans software sources looking for javadoc and reports the health status of javadoc documentation, the latter scans source code looking for patterns that could reveal tyipical bugs.

Time Table

To make gCube (and gCore) components integration "continuous", software is automatically built on regular basis (typically daily).

• org.gcube.HEAD and org.gcore.HEAD configurations are built once a day (usually at midnight) by a Build Server sitting in Building Infrastructure. Artefacts and reports are available at this BTRT page: http://grids16.eng.it/BuildReport/browse/Recent_Builds/org.gcube.HEAD and http://grids16.eng.it/BuildReport/browse/Recent_Builds/org.gcore.HEAD
• during a Release Cycle, software for that release is built twice a day usually at midnight and at midday

Summarizing, these are all scheduled builds running in Building Infrastructure:

External Links

• Continuous Integration by Martin Fowler