Version control

Version control tracks and coordinates revisions to a set of resources (typically program source files) and makes it easier for multiple authors to revise files and maintain document integrity. The cPath project uses CVS (Concurrent Versions System - http://www.cvshome.org/). There are more advanced version control systems available these days, but CVS is free, the de facto standard and sufficient for our needs.

Issue tracking

Issue tracking has the following advantages:

• Track bugs, feature requests and TODO items in a structured way.
• Provides a single well-known place to look for information on bug and feature reports until they can be acted upon
• Bugs and features can be searched for similar past issues
• Allows us to report back to end users

Regression testing

Regression testing is the developer centric process of running an automated test suite to find out if recent changes have broken the software. cPath uses the freely available JUnit tool (http://www.junit.org), which requires unit tes ts to be written for each test. An example test would read in a file and check to see that values read from the file are properly stored in memory after the read operation.

It is recommended that developers write unit tests, that these tests are organized into suites, and that all tests be organized to run from the single ant 'test' target. This makes regression testing easier. Unit tests are currently organized so they can be run individually and locally if desired. Full details are available in the cPath.unitTests.AllTests class.

Integration and release testing

This user-centric quality assurance process involves a typical user testing the application on a typical platform. Currently cPath does not have dedicated QA staff, but a minimal integration test process is performed by the development team members before any major software release.

Documentation

There are four types of documentation considered here.
• Operations manuals (protocols) describe how we do things here. This document is an example. cPath currently does not have many operations manuals, although it is not yet clear if the project requires them. Some types of operations manuals that could be useful are:
• How to release a new version of cPath
• Software development process (this document)
• How to contribute
• Others?
• User guides are typical user documentation. cPath currently has some useful user documentation (e.g. an installation guide), although the newest features are not always described.
• Development (technical) documentation describes architecture, APIs, classes and methods. cPath uses the freely available JavaDoc system to document the code and has been using the freely available Maven 'project comprehension' system for storing these documents in XHTML format (used by the xdocs Maven plugin). A number of XHTML editors are freely available including Amaya and Mozile (th e Mozilla editor), although we've found it easier to just edit these documents with a simple text editor.
• Project management documents include software status reports and implementation plans. These should be posted on the Maven site.

Analysis and estimation (A&E)

Feature prioritization and planning are important things to consider in any software development project and should allow the most important features to be implemented to a stable level first. Currently, cPath performs A & E in weekly meetings in the Sander group.

Build Process

cPath is currently built using Ant scripts. Ant also automates testing and other tasks as well. Changes to the build process should be localized to the single build.xml file for clarity.

User testing protocol (integration and release testing)

A minimal set of user tests should be performed before a public cPath release. This should include some basic tests, such as loading up a few data sets and testing the web site. This should be done at least to ensure basic functionality before a release. Ideally, more testing should be done before a release, but the project currently doesn't have a dedicated QA person. If one becomes available, then this protocol should be expanded.

Release protocol

Internal releases should be made every month. This allows new projects (e.g. plugins) that need to be based on a stable core) to get started within the group. The internal release should include the following steps: regression and integration testing, tagging the CVS repository with a release tag and documenting the release tag on a web page. This release should be certified as stable and subsequent development of internal release of software (e.g. to internal users) should use this codebase. Subsequent inter-release development could continue in t he CVS repository, but that code should not be distributed to most users until the next stable release.

Public releases should occur when significant new features have been added to cPath. A larger amount of integration testing should occur before public release than for an internal release. User documentation should be updated and the binaries should be posted to the cPath.org website.

Communication

The following communication tools are typically used in cPath development:

• Weekly technical meetings