Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Development/Memos/Sprint Release Workflow

From TYPO3Wiki
Jump to: navigation, search

Thoughts for a better “sprint release” workflow after 7.0 release headaches

Problems we’ve seen with past releases and with 7.0 again

  • Bugfix merges shortly before release day: Real-life testing happened way too late, some patches were done last minute.
  • Unrelated merges shortly before release day: Contributors with merge rights were not aware of upcoming release and merged non-critical patches at release day that could potentially harm.
  • Late concerns about postponing: With bugs that popped up at release day it was the question if the release should be postponed for hours / days / weeks
  • Rushed bugfixes: Late bugfixes are a risk to quality. “This solution is ugly, but we must fix it now, go for it”
  • Stress, bad mood and chaos
  • Outer and inner communication not prepared at time: “Who takes care of Release notes in the wiki”, “The banner can not stay this way” and “What to do next?”
  • We should remind everybody of looking into forge etc. a week after the release for new issues that get reported to fix them immediately.

Goals

  • The actual release day should be “smooth”: Just push a button and be sure everything is fine.
  • Ideally, we could say 2 days before release “Hey, actually we can press the button now, we’re ready”
  • Keep promises: Stability & release dates. No postponing
  • Have rules for mergers / active contributors: What is allowed at what time
  • Be prepared: Release day shouldn’t come unexpected, bugs shouldn’t be handled last-minute, documents should be ready
  • Have topics for next sprint ready: Focus on next cool things immediately

Better sprint release structure

The new release cycle gives us all we need at hand. We can release early and often, have releases in a stable and usable state, and still have tons of features merged. We just need to live it. In general we expect that the number of huge-area-patches shrinks: There shouldn’t be that many patches that change literally *all* php files at the same time (like general cgl patches). Having less of those makes working on bigger features in certain areas much less painful when it comes to rebasing. Patches cross-cutting tons of files because of systematic changes should therefore only be done in the “beginning” phase of a LTS cycle, when big functional stuff is not in the works or at an early state. Deprecation removals throughout the core are done at the beginning of a LTS cycle as well.

Sprint release phases

1. “Features” - Main feature phase & casual bugs: Merge big stuff as early as possible. They should be ready, codewise working and fine from an architectural point of view already. Big stuff should be prepared in a fork and not developed in master. If big stuff can be split into small pieces, it is a good idea to have small and encapsulated patches merged in this phase. This phase is about integration, not about development: Big stuff already had its blueprint phase, ideally one or more people taking responsibility in this area and main development is finished. The impact of big stuff is known, and there is a todo list for missing parts that can be done within the sprint.

    • Examples for “big” stuff:
      • Integrate composer and move all files around
      • Integrate doctrine DBAL and change all db calls
      • Integrate Twitter Bootstrap
      • Integrate a new tree approach
      • ...

2. “Small stuff” - Small feature phase & casual bugs: Smaller and encapsulated features can still be done here.

    • Examples for “small” stuff:
      • Change specific areas from prototype to AMD / RequireJS
      • Add a stdWrap option in TypoScript
      • Change details of the Logging API
      • ...

3. “Stabilization” - Bugfix & revert phase: Latest timeframe where big stuff and main features are reverted because they are not finished or can not be stabilized in time. Smaller bugfixes are integrated here, no features and no cleanup patches anymore. Finish last loose ends of bigger stuff that can be stabilized in time.

4. “Soft merge freeze” - Real live testing & release preparation phase: Only release blockers are merged here, no casual bugfixes anymore! Release notes are prepared, “Who will press the button” question is solved, press releases are prepared and proof read, documentation topics are solved. Decision for postponing a release is done here. Only exceptional core merges signed off by release team!

5. “Release phase” - Everything is prepared here, no merges at all

Timings

  • Features” and “Small stuff” phase is probably not very distinct in the starting phase of the the new release cycle. In future we expect to have a more clear distinction here. If a “sprint release” is anticipated for 10 weeks, main feature phase should be done after ~ 7 or less weeks. It may be aligned with the end of real-life sprint meetings.
  • Stabilization” phase should be around 2 weeks: It should give the opportunity to fix the one or the other detail and to take decisions whether a specific feature should be reverted.
  • Soft merge freeze”: 3 to 5 days before release day.
  • Release phase”: 2 days

Rules and tools

  • Slack “botty” could help us with communicating the current phase to active contributors
  • Reverting is ok: If a “casual” unrelated bugfix is merged during “Soft merge freeze” it should be reverted immediately.
  • Reverting is ok: If a big feature is not stable, it should be reverted better sooner than later, we should ask then how this could happen
  • Active contributors must understand and follow the workflow. Main reason is “We want a relaxed and stable release in time”

Task List / To Do to prepare for a release

  • What's new slides
  • Release Notes
  • Wiki Page with content
  • Migration things we need to take care (what will break?)

Testing scenarios during stabilization phase

  • Upgrade from 6.2 to 7.x directly
  • Upgrade from 7.0 to 7.x directly
  • Upgrade from 7.x-1 to 7.x
  • New Installation
  • Distributions