Jump to: navigation, search

Difference between revisions of "Orion/Continuous Delivery"

(Builds)
(Stable build process)
Line 37: Line 37:
 
# On Monday at 12:00 ET / 18:00 CET a new stable branch is created of the form stable_YYYYMMDD
 
# On Monday at 12:00 ET / 18:00 CET a new stable branch is created of the form stable_YYYYMMDD
 
# A committer designated as the Integrator reviews all changes in master and merges into the stable branch
 
# A committer designated as the Integrator reviews all changes in master and merges into the stable branch
# A stable build is performed against the stable branch and promoted to orion.eclipse.org
+
# A [https://hudson.eclipse.org/orion/job/orion-client-stable/ stable build] is performed against the stable branch and promoted to orion.eclipse.org
 
# Committers test orion.eclipse.org and further stable builds are run as needed
 
# Committers test orion.eclipse.org and further stable builds are run as needed
 
# The build is promoted as stable with the naming convention S# where # is the sequential stable build number since start of the release cycle
 
# The build is promoted as stable with the naming convention S# where # is the sequential stable build number since start of the release cycle

Revision as of 09:00, 17 July 2014

This page collects ideas, processes, and technology requirements for supporting continuous delivery of Orion

Overview

For the past couple of years, the Orion project has followed an abbreviated version of the classic Eclipse milestone development process. Each release consisted of two 6 week milestones, followed by a 5 week end-game, for a roughly 4 month total release cycle. This release cadence works well enough for classic software that is released and delivered to customers, but is not acceptable for Orion consumers building hosted software services. Four months is far too long to wait to update a web application. Other related web technology such as browsers and web frameworks are releasing much faster, and security bugs often require very fast (even zero day) turnaround.

This page captures the Orion community's efforts to move from three releases a year, to an interim goal of releasing stable builds once a week.

Planning

Builds

Orion runs with two classes of builds:

Build Type Branch Frequency Deployed To
Dev master Daily or on demand orion.eclipse.org
Stable stable_YYYYMMDD Weekly orionhub.org

Stable build process

Each week we converge to produce a single stable build using the following process:

  1. On Monday at 12:00 ET / 18:00 CET a new stable branch is created of the form stable_YYYYMMDD
  2. A committer designated as the Integrator reviews all changes in master and merges into the stable branch
  3. A stable build is performed against the stable branch and promoted to orion.eclipse.org
  4. Committers test orion.eclipse.org and further stable builds are run as needed
  5. The build is promoted as stable with the naming convention S# where # is the sequential stable build number since start of the release cycle

Release process

Every four months a stable build is promoted as a release.

Testing

Automated testing

Controlled access for new features

Communication

New and noteworthy