This page was last modified on 23 December 2015, at 20:37.
Apache Continuum is an enterprise-ready continuous integration server with features such as automated builds, release management, role-based security, and integration with popular build tools and source control management systems. Whether you have a centralized build team or want to put control of releases in the hands of developers, Continuum can help you improve quality and maintain a consistent build environment.
Apache Continuum, a partner of Apache Maven, is a cross-platofrm continuous integration and build server written in Java programming language. Continuum runs builds on a configurable schedule. Much like CruiseControl, Continuum sends notifications to developers when the build is broken, requesting that the culprit fix the problem.
Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day. It was first named and proposed by Grady Booch in his 1991 method although Booch did not advocate integrating several times a day. It was adopted as part of extreme programming (XP), which did advocate integrating more than once per day, perhaps as many as tens of times per day.
The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.
In XP, CI was intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests in the developer's local environment and verifying they all passed before committing to the mainline. This helps avoid one developer's work-in-progress breaking another developer's copy. If necessary, partially complete features can be disabled before committing using feature toggles.
Later elaborations of the concept introduced build servers, which automatically ran the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP.
In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes.
In the same vein, the practice of continuous delivery further extends CI by making sure the software checked in on the mainline is always in a state that can be deployed to users and makes the actual deployment process very rapid.
Continuum offers the following features:
- Easy installation: Download the standalone application and run it or deploy the Continuum WAR in your servlet container;
- Easy configuration: Project's builds are auto-configured but they can be configured easily with the web interface;
- SCM support: CVS, Subversion, Git, Clearcase, Perforce, Starteam, Visual Source Safe, CM Synergy, Bazaar, Mercurial are supported;
- Change set support: For each build result, Continuum prints all SCM changes (commit authors, commit logs, modified files);
- Build notification: Mail, Jabber and Google Talk, MSN, IRC, report deployment with wagon;
- Build tool support: Maven, Ant and shell build types are supported;
- External integration: External tools can interact with Continuum via XMLRPC API;
- Build type: Manual, scheduled and push (via xmlrpc) are supported;
- Build template: Users can define default build templates to use by project type;
- Build queue: Users can view all projects in the queue and even interrupt active builds;
- Distributed builds: Projects can be distributed to remote hosts using build agents;
- Parallel builds: Projects can be built concurrently using multiple build queues.
Getting started with Continuum's default configuration is very easy. First of all you need to install it
svn co http://svn.apache.org/repos/asf/continuum/all continuum-all cd /path/to/continuum-all/parent mvn install cd /path/to/continuum-all/continuum mvn install
After a successful build, you will find the Continuum distributions in continuum-jetty/target and the WAR file in continuum-webapp/target.
After unpacking the binary distribution, run the following command from the bin directory:
Continuum will be started from the command line and run until quit with Ctrl-C. For more instructions on installing Continuum as a service or under an existing application server, refer to the Installation Guides.
When you start Continuum for the first time (without an existing database), the first thing you will do is create the administrator account and perform the General Configuration.
After the administrator account has been created, you can log as the admin user with the password you selected. The next thing you will see is the General Configuration page.
The defaults are usually sufficient, so you can save the configuration. You may later make changes to this page if you are enabling Distributed Builds, for example.
Once the server is running, you will likely want to do the following:
- Create more users via the Users menu item, so that you no longer need to use the administrator account for daily tasks;
- Add Projects to build;
- Configure Continuum to work with distributed builds if you intend to have multiple build slave machines
- Configure installed software packages and environment variables for project templates
Cite error: Invalid
parameter "group" is allowed only.
<references />, or
<references group="..." />