User:Mstone/Commentaries/Releases 3

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

We make changes to our software for many reasons; however, we make scheduled (major) releases in order to deliver significant changes to our downstream partners. Major releases may include interface-breaking changes. They are different from unscheduled (minor) releases in that they contain larger and more thoroughly planned changes.

Framework

Scheduled software releases obviously consist of work on four broad and overlapping topics:

1. planning: Figuring out what to do.
2. development: Generating changes which may help to meet the new goals.
3. release: Integrating the changes in a controlled fashion.
4. deployment: Helping downstream partners adapt to the new release.

However, this rough breakdown offers little concrete guidance on important issues like:

• what can we reasonably expect to do?
• how should we divvy up the work?
• what may go wrong?
• how do we tell if it's going well or poorly?
• how can we do it more, better, faster, cheaper, more clearly, etc.?

To answer these questions, I have turned to other tools: control theory, concurrent systems theory, and a limited theory of my companions' psyches.

Control theory is applicable because the goal of a software release is to hit a moving target by making many small changes subject to regular feedback.

Concurrent systems theory is applicable because it provides great vocabulary for describing how the actual work gets done and for its analysis of failure.

Finally, people (psyches) must be considered because we're trying to combine the labor of a fairly specific group of rather quirky and miscommunication-prone individuals rather than of a network of identical processors running identical software.

Observations

Here's a word-picture of the problem of making a release drawn from the framework above:

       efficiency    deadlock    progress    trade    desires  involved
  starvation      feedback     objectives     strategy    resources     ship
consensus     authority     informed     stale     wasted   confused  supported
  competition     race      disagree      risk      affordable   rebuffed
     slip      cut      broken     hacked-up     tested   engaged    burned 
       know    evidence     signoff     stuck     waiting    queue     rest
     consent      responsible    accepted      consulted     contract  sick
 production    merge      freeze      slush      candidate    criteria   vacation
       frequency     magnitude     severity     priority     window   prototype
    blocker     polish     demotivated      process     approved    workflow
 quality     performance     usability    security    correctness    interoperability
   change       integrate       assure      document      release      rebase   use
        delegate       stovepipe      drop        announce      decide      team

Objectives

Write an Objectives page (e.g. 8.2.0) recording a consensus on:

• target month.
• development goals and priorities.
• lead customers.
• feasibility of proposed changes.

Module maintainers, product management, and the release team will be responsible for building and maintaining this consensus based on communal, customer, and institutional feedback. All three groups will be responsible for acting to achieve its mandates, e.g. as advisers, maintainers, and managers.

Schedule

We have learned that certain minimum amounts of time must be allocated to integration and testing. The following example schedule records some of this knowledge:

1. >60 days before target date Steam. Changes can be proposed at will and should be proposed as early as possible.
2. 60-30 days before target date Water. Proposals must pass muster with the release team. Release contracts should be written and integration should occur. This is feature-level change control.
3. 30 days before target date Ice. We branch for release and the release team produces release candidates as needed under package-level change control. Developers should be focused on fixing bugs.
4. <15 days before target date Final Test. Get consensus from test, QA, and engineering communities, then finish the Release Process Checklist.
5. Release day. Announcement Day. Once Release checklist is complete, Kim sends announcement e-mail approving release for production.

DEVELOPMENT

Development consists of creating potentially releasable changes during a Steam period (no change control) and a Water period (feature-level change control).

Steam

Occurs: MORE than 60 days before target date

Prior to the transition to Water (feature-level change control), there is great freedom to propose changes because resources have not been allocated toward integrating and testing the proposed changes. We allocate these resources with release contracts.

Water

Occurs: 60-30 days before target date

When Steam transitions to Water, changes requiring reallocation of integration, test, or downstream resources (i.e. requiring a new release contract) will require approval by module maintainers and the release team before being accepted. Minor changes can still be added without approval until the transition to Ice. Changes requiring great coordination to deliver like string changes and UI changes will be deferred if possible.

By the end of Water, developers are expected to have created release contracts for each desired change. See previous examples.

RELEASE

Release consists of integrating desirable changes created during development, then executing the Software ECO process to finalize the result.

Ice

Occurs: 30-0 days before target date

When Water transitions to Ice, the release team will branch the development stream twice creating updates and testing build streams.

• Both the updates and testing streams will be placed under package-level change control by the release team.
• The updates stream will be used to house packages being considered by the release team for insertion into the testing stream.
• Official QA will consider builds from the testing stream. When approved by official QA, these builds can become release candidates as part of the underlying Software ECO process being executed by the release team.

During this time, developers are expected to contribute in any way they can to the construction of the release. Any other work, e.g. work done on personal time, can be performed on a separate development stream.

DEPLOYMENT

Upon completion of the Software ECO process, a new reference operating system is made available. However, further work must be done to adapt this component to the needs of downstream partners.