Simplified and Reusable Release Process

Overview

Phases of a Release

• Release planning: Wish list, tasking, release plan
• Open coding on new features
• Feature freeze: time to slow down and focus on the details of the whole product across layers
• Code freeze: QA time! Only blocker bug fixes.
• Tying it all up: release packaging, demo install, and announcements

Release Flow

Planning a Release

1. Set a release date. Work backwards from here. It's generally good form to not choose a Friday or a holiday. Determine other key dates:
   • Feature freeze date
   • Code freeze date
2. Create a release wish list. This contains the functionality we'd like to add to the release.
3. Tasking: find out how much work we can actually get done in time for the release
   • Each developer breaks down a given user story into the tasks they'll need to do
   • For each task, the work is estimated, including time for collaboration and integration across layers
   • This is where vacation time, local concerns, or other issues can be accounted for in the plan
   • Estimates can be derived using whatever technique each person is most comfortable with
   • As a community, we trust each others' estimates to be realistic and invested (this is not an opportunity for contention)
   • Each of your tasks should go into JIRA, along with the time estimates. These should be visible with a release-related filter
4. Define the release plan
   • Decide which subset of features in the wish list can be done within the allotted time
   • Create a list of achievable features for the release
   • This release plan should be available in JIRA as a filter so we can all see the tasks involved
5. Start the process of integration right away:
   • STIMs, mailing list conversations, and so on; ensure we have a constantly integrated product

Feature Freeze

In some ways the phrase "Feature Freeze" is a misnomer as it is a stage and not a moment in time (i.e. something still and frozen).

The feature freeze stage is a checkpoint in the release process; it's an opportunity to slow down, reassess priorities midway through the release cycle, and focus on whole-product integration of the most important features and fixes. The feature freeze stage is a natural check-in point to see where we're at and ensure our progress is well-communicated. This stage involves:

• Checking in on progress among all tasks across all layers. How are we tracking against plan?
• Reaching agreement on which are the on highest-priority features that still need to be implemented
• A good time to defer weaker features or ones that won't be finished in time for code freeze
• Updating the release plan based on our progress so far
• Starting to develop QA test plans for each feature in the release

Code Freeze and QA

The code freeze and QA phase is an opportunity for the whole community to focus on the quality and details of the product. This phase involves:

• An opportunity to be systematic about testing the entire product
• Everyone, from design to development, helps with testing
• No new code commits unless they specifically address a blocker bug found during QA testing

Who Does What?

Every phase of this release process inevitably involves a lot of community input and involvement. This chart outlines who might help to keep the release flow going by organizing a particular activity.

Prerequisites for Successful Releases

1. A clear, well-communicated, mutual understanding of key milestones, phases and dates for a release
2. A clear release checklist, describing:
   • Key activities during each phase of the release: choosing a release manager, how JIRA is organized, etc.
   • How to build, verify, install, and run the entire application, step by step
   • How to organize, cut and tag, deploy, and announce a new release
   • All this information should be described in Release Process
3. The ability to create integrated builds on a constant basis
   • Always have a fresh, full stack version of "Project" visible – a daily build
   • Currently, this will require us to invest up front in build automation
4. Enough information and/or collaborative availability that teams can cross architectural boundaries to help out when needed