Difference between revisions of "Continuous Integration procedure"
From Gcube Wiki
Luca.frosini (Talk | contribs) (→Build Activity) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 3: | Line 3: | ||
== Introduction == | == Introduction == | ||
| − | Continuous Integration is a well known procedure in software development that aims to reduce time to | + | Continuous Integration is a well known procedure in software development that aims to reduce time to deliver software improving its quality. Continuous Integration consists of 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. [http://www.nongnu.org/cvs/ CVS], [http://subversion.tigris.org/ SVN]) | * keep '''source code in repository''', preferably a Version Control System (e.g. [http://www.nongnu.org/cvs/ CVS], [http://subversion.tigris.org/ SVN]) | ||
| − | * automate builds '''on daily basis''' (or even more frequently) | + | * 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 | * 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 | + | * builds are ''self-testing''. Source code includes tests that are automatically 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 | * developers '''commit on mainline of source repository as frequent as possible''', keeping the mainline builds successfully | ||
== Continuous Integration of gCube System == | == Continuous Integration of gCube System == | ||
| − | + | All gCube source code is maintained in centralized SVN Repository. Further details on this can be found in the section [[gcube subversion repository|gCube Subversion Repository]]. Development guidelines ask developers to provide one (or more) test-suites to test modules they develop. | |
| − | + | Automatic builds of the entire gCube System software are scheduled on the [[Integration Infrastructure|Integration Infrastructure]] on daily basis. Two versions of software are built: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Automatic builds of the entire gCube System software are scheduled on the [[ | + | |
* gCube Development Configuration (org.gcube.HEAD): the latest version of gCube source code is built to quickly reveal and fix integration problems | * 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 [[Major/Minor Release Cycle procedure|Release Cycles]] or [[Maintenance Release Cycle procedure|Maintenance Cycles]], candidate configuration is built to solve all integration problems | * gCube Release Candidate Configuration: if there is an ongoing [[Major/Minor Release Cycle procedure|Release Cycles]] or [[Maintenance Release Cycle procedure|Maintenance Cycles]], candidate configuration is built to solve all integration problems | ||
| Line 28: | Line 20: | ||
==== Development Configurations ==== | ==== Development Configurations ==== | ||
| − | In [[ETICS|ETICS]], | + | In [[ETICS|ETICS]], each component has a "special" configuration called: ''org.gcube.<component-name>.HEAD''. This configuration points, at any time, to the latest source code available on the SVN repository. To be valid, any valid *.HEAD configuration has the ''tag'' field pointing to svn repository's trunk and has not a revision number set. Development configurations also exist for all subsystems and for the whole project. The latter is named '''org.gcube.HEAD'''. |
<pre> | <pre> | ||
| Line 49: | Line 41: | ||
==== Integration Configurations ==== | ==== Integration Configurations ==== | ||
| − | When a [[Major/Minor Release Cycle procedure|Release | + | When a [[Major/Minor Release Cycle procedure|Release Cycle]] or a [[Maintenance Release Cycle procedure|Maintenance Cycle]] start, components to be included in the upcoming version are delivered 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. |
<pre> | <pre> | ||
| Line 74: | Line 66: | ||
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. | 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 [[ | + | Builds are executed by a Build Server in the [[Integration Infrastructure|Integration Infrastructure]]. When a build is scheduled, these are the steps executed on the build server that will perform the build: |
# source code is downloaded from gCube code repository(ies) executing '''etics-checkout''' command; | # source code is downloaded from gCube code repository(ies) executing '''etics-checkout''' command; | ||
# some statistics on source files types are collected. Later on, they will be available in [[BTRT|BTRT]]; | # some statistics on source files types are collected. Later on, they will be available in [[BTRT|BTRT]]; | ||
# source code is built executing ( '''etics-build''' command); | # source code is built executing ( '''etics-build''' command); | ||
# artefacts, checkout and build logs, ETICS reports, plugin reports are published in the repository; | # artefacts, checkout and build logs, ETICS reports, plugin reports are published in the repository; | ||
| − | # '' | + | # ''distribution'' task is launched on the published build; |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | |||
| − | + | ETICS allows (if properly configured) execution of a number of plugins during '''etics-build''' execution. Currently two plugins are executed during builds: [http://checkstyle.sourceforge.net/ '''checkstyle'''] and [http://findbugs.sourceforge.net/ '''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 typical bugs. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== External Links == | == External Links == | ||
* [http://martinfowler.com/articles/continuousIntegration.html Continuous Integration by Martin Fowler] | * [http://martinfowler.com/articles/continuousIntegration.html Continuous Integration by Martin Fowler] | ||
Latest revision as of 23:58, 3 November 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
Contents
Introduction
Continuous Integration is a well known procedure in software development that aims to reduce time to deliver software improving its quality. Continuous Integration consists of 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 automatically 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
All gCube source code is maintained in centralized SVN Repository. Further details on this can be found in the section gCube Subversion Repository. Development guidelines ask developers to provide one (or more) test-suites to test modules they develop.
Automatic builds of the entire gCube System software are scheduled on the Integration 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, each component has a "special" configuration called: org.gcube.<component-name>.HEAD. This configuration points, at any time, to the latest source code available on the SVN repository. To be valid, any valid *.HEAD configuration has the tag field pointing to svn repository's trunk and has not a revision number set. 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 start, components to be included in the upcoming version are delivered 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
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 Integration Infrastructure. When a build is scheduled, these are the steps executed on the build server that will perform the build:
- source code is downloaded from gCube code repository(ies) executing etics-checkout command;
- some statistics on source files types are collected. Later on, they will be available in BTRT;
- source code is built executing ( etics-build command);
- artefacts, checkout and build logs, ETICS reports, plugin reports are published in the repository;
- distribution task is launched on the published build;
ETICS allows (if properly configured) execution of a number of plugins during etics-build execution. Currently two plugins are executed during 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 typical bugs.
