IceCube Software Development Process

This is a high-level document describing, in general, the development process for all IceCube software efforts.

Table of Contents

  1. Overview
  2. Documents
    1. Release Plan
    2. Test Plan
    3. Development Schedule
  3. Tools
    1. Version Control
    2. Bug/Feature Tracking
    3. Configuration Auditing
  4. Specifications
    1. Execution Environments
    2. Release/Build Environments
    3. Testing Environments
    4. Development Environments

1. Overview

This is not project specific but describes the essential documents, roles, tools and specifications which must exist in all software IceCube efforts.

2. Documents

The following documents must exist for each software effort. These docs will refer to each other and may be revised and/or specific to each release.

2.1 Release Plan

This identifies the goals of a specific release: what is being fixed, added or removed, if this is a major or minor release, etc. It identifies who certifies the release (based on successful execution of the Test Plan), and how that release is deployed/distributed, recorded and announced.

2.2 Test Plan

This a per-release document which details the the set of tests to be executed, who executes them and who verifies their runs.

2.3 Development Schedule

A schedule of development milestones and responsible parties, including full, minor and patch releases.

3. Tools

Various tools which need to accomplish the following tasks will be used by each IceCube software effort.

3.1 Version Control

Which of cvs, svn, or bfd is used is less important than that release candidates and certified releases can be rebuilt from known tagged/delivery points. In conjunction with the below described environments, a release should be completely reproducible.

3.2 Bug/Feature Tracking

A database for tracking bugs and feature requests. This can also be used for more than just tracking defects but also for tracking schedules and project management.

3.3 Configuration Auditing

A definitive and authoritative mechanism of identifying deviations from the correct configuration of the below described environments - including the underlying system, dependencies and IceCube software itself. This is to provide an automated and relatively objective way to insure that the configuration of the environments is intact.

4. Specifications

Each software effort needs to identify the specifications required for the various environments used in their projects. These include at a minimum the following environments.

4.1 Execution Environment

Detailed description of the environment in which the software is expected (and has been certified) to run. For some projects this may be one and only one systems (i.e. the SPS) for others is may be many different workstation platforms.

4.2 Release/Build Environment

Detailed description of the specific machine (or set of machines) where the released software is compiled into it's distributable form (binaries, rpms, etc.). This environment will need to be compatible with the execution environment(s).

4.3 Testing Environments

There will likely be multiple testing environments (for various tests and platforms) but for each one a specification should be created for accuracy and reproducibility of tests.

4.4 Development Environments

This is potentially is the most flexible environment but a minimum specification of a developers 'sandbox' should be documented. Not only to identify supported development platforms but also to aid in developers coming up to speed.