Difference between revisions of "COSMOS dev process"

Revision as of 16:08, 10 September 2007

DRAFT: COSMOS Development Process

Development & Testing

Enhancement Requests

• At any time during the release cycle, enhancement requests can be submitted by creating a bugzilla entry.

Iterations

• An iteration is a 4-6 week period consisting of requirements, design, code and test activities, the output of which is a stable, integrated and tested release of the system.

The following steps are required for each iteration:

1. Identify and accept requirements:

• Each subproject team should review open enhancement requests, prioritize them based on the release themes and use cases, and assign them to a development resource.
• A review of the requirements list for all subprojects will be completed during the COSMOS Community call prior to the start of the iteration for final acceptance.

2. Complete Designs:

• Assigned developer(s) should create designs and post them on the COSMOS wiki for Community review.

3. Complete Coding/Implementation:

• Assigned developer(s) should check code into CVS to be integrated into the build.

4. Complete Test Pass:

• During the iteration test phase, the code base is frozen. Each subproject should run the appropriate test cases, and check in only fixes for problems found during testing.
• Once a subproject team determines that the test has completed successfully, the team lead should post a message to the dev mailing list indicating that the test pass for the subproject is complete.
• Once all subprojects have confirmed successful completion of the test pass, the release engineering team will generate a candidate build.
• Each subproject team is responsible for doing a final test pass against this build.
• All tests should be in CVS as COSMOS manual and JUnit tests

Iteration Exit Criteria

• No high severity defects and 100% test attempt/pass (95% pass on early iterations)
• Test results posted; All exceptions reviewed before deferral/discharge

Daily Builds

Release Engineering Team

• The Release Engineering Team will be responsible for seeing to it that the builds and tests run to completion.
• In the event of problems with the build & test system itself they are expected to resolve them as soon as possible and get the build and test restarted.
• In the event of problems with the build caused by developer checkins they are expected to follow up with developers to ensure fixes are made quickly, and then get the build and test restarted.
• Any build failure will be reported as a bugzilla to the build component for tracking of the actual issue as well as trend analysis, etc.

Ownership

• All committers are responsible for clean builds and tests. Clean daily builds and tests keep the system stable, prevent regressions, and avoid down time. Anytime you check something in, you are responsible for monitoring the builds and tests until they pass. This means that for at least 24 hours after your checkin, you are available, responsive and prepared to help with any issues that crop up.

Nightly Builds

• Every 24 hours at GMT-5 10:00 PM (EDT) the state of the HEAD branch of the CVS repository will be labeled with a time stamp
• The time stamp will be encoded with the release number, date, time, and serial build number: COSMOS-RMm-YYMMDDHHMMSS
• A module list will be maintained (in CVS) that list all the modules that are part of the current build, labeling and extracting will be restricted to those modules. This could be a PDE build style map file or .pfd file. This map file will be named COSMOS-RM.m.{map|pfd} and will be labeled with the time stamp at build time as well.

Nightly Tests??

• Where are build and/or test results posted?

Milestone Releases (MS)

• Milestone releases, which will be spaced out across the release schedule, contain complete DCUT (code complete, unit tested) increments of functionality (they are a subset of the full functionality of the target release).
• Milestone releases are number RVM.m.MS1 through RVM.n.MSn (R1.0.MS2 for example).
• A milestone release is created by relabeling and renaming a GOOD build, updating the downloads page and sending out an email saying the milestone release is available. The contents of the milestone are determined by the project schedule.
• Users can look at the download page and find latest milestone release.

Release Candidates (RC)

• Near the end of the project when all tests have been run, bugs fixed, and the builds are stable, the release engineering team will promote a release candidate build.
• Release Candidates are number RVM.m.RC1 through RVM.n.RCn (R0.4.RC7 for example).
• A release candidate is created by relabeling and renaming a GOOD build, updating the downloads page and sending out an email saying the release candidate is available.

GA Builds (GA)

• A GA build is created by relabeling and renaming a GOOD release candidate build, updating the downloads page and sending out an email saying the GA release is available.
• A release candidate build can be declared GA when the following criterion have been satisfied:
  • No high severity defects and 100% test attempt/pass
  • Test results posted; All exceptions reviewed before deferral/discharge