User:Mstone/Commentaries/Releases 3: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 74: | Line 74: | ||
#* The transition to ''Water'' occurs when all release contracts are signed. |
#* The transition to ''Water'' occurs when all release contracts are signed. |
||
# 60-30 days before target date is '''Water'''. |
# 60-30 days before target date is '''Water'''. |
||
#* This is ''feature-level change control'' -- changes requiring reallocation of integration, test, or downstream resources (i.e. requiring a new release contract) |
#* This is ''feature-level change control'' -- changes requiring reallocation of integration, test, or downstream resources (i.e. requiring a new release contract) are now likely to be deferred. |
||
#* 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. |
#* 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. |
||
# 30 days before target date is '''Ice'''. |
# 30 days before target date is '''Ice'''. |
Revision as of 00:19, 14 June 2009
![]() |
NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... |
![]() |
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:
- planning: Figuring out what to do.
- development: Generating changes which may help to meet the new goals.
- release: Integrating the changes in a controlled fashion.
- 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 plan believable insane ideal predict guess stall critical-path root-cause time budget schedule complex
Good Ideas
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.
Responsible parties like 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.
Release Contracts
A release contract is an agreement between the release team and one or more contributors to attempt to integrate some desirable change into a release build.
Release contracts normally describe:
- the required quality of an acceptable change,
- a test plan for judging the quality of a proposed change, and
- who will execute the test plan.
(Typically, violation of a release contract will result in deferral of the proposed change.)
Examples are available. See our Trac conventions for help interpreting the display.
Schedule
We have learned that certain minimum amounts of time must be allocated to integration and testing. We conceptualize this requirement by thinking of the release as passing through several necessary "phases", arranged like so:
- >60 days before target date is Steam.
- Changes can be proposed at will and should be proposed as early as possible.
- There is great freedom to propose changes because resources have only been loosely allocated toward integrating and testing the proposed changes.
- The transition to Water occurs when all release contracts are signed.
- 60-30 days before target date is Water.
- This is feature-level change control -- changes requiring reallocation of integration, test, or downstream resources (i.e. requiring a new release contract) are now likely to be deferred.
- 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.
- 30 days before target date is Ice.
- Ice begins when we branch for release so that the release team can produce release candidate builds as needed under package-level change control.
- The effect of this change control is that fixes -- often for "blockers" or "polish" -- are more selectively merged.
- You exist Ice by executing the Software ECO process and its accompanying Release Process Checklist.
- Release day. Announcement Day. Once Release checklist is complete, you're done!