Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Orion/Continuous Delivery
This page collects ideas, processes, and technology requirements for supporting continuous delivery of Orion
Contents
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
We will continue to plan around four month release cycles, but will revise the plan monthly based on progress, new issues, changing priorities, etc. Orion plans are found in the Orion project portal.
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:
- 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 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
- 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. In the Git repositories, releases are given a tag of the form Rx_y for the x.y release. For example R6.0 (client, server) for the Orion 6.0 release. Release source code can be downloaded using those tags. Release binaries are made available on the Orion download page.
Testing
Automated testing
Every dev and stable build runs a full suite of automated unit tests against both client and server components. Further integration testing is done by "self hosting" at orion.eclipse.org prior to release.
Controlled access for new features
Significant new features should be introduced in the main code base early, either on a separate, unlinked URL, or by using some form of feature toggle. Some options for implementing feature toggles in Orion:
- Put the UI portions of the new feature in a plugin that is not installed by default. Early adopters need to install the plugin to get the feature.
- A major page overhaul can be done by introducing a duplicate page that is not linked elsewhere. Early adopters need to know to navigate to that URL to see the new page. The feature is launched by switching URLs to the new page. Once feature is accepted the old page should be deleted to avoid cruft.
- Use a temporary setting that is disabled by default, and adopters need to know to turn it on. Once ready for more exposure the default can be changed to on, and then remove the setting entirely.
- Use a query argument in the URL to control access to a feature. User needs to alter the URL to see the feature.
Communication
New and noteworthy
Since we no longer have milestones as an opportunity for collecting and announcing new features, we will instead strive to blog about new features once they are available. We need to be clear when posting whether it is a feature in an existing release, or something for an upcoming release. We will continue to use Planet Orion for posting about new features, in addition to the @orionhub twitter account.
Legal clearance
We will continue to do a full Eclipse release process every four months, with the full associated Eclipse legal review process. However, we should strive to always be in an "IP cleared" state. This means:
- Never introduce a third party library until it has gone through Eclipse IP review (CQ)
- Don't accept patches longer than 1000 lines until it has gone through CQ review
- Only consume code from official releases of other Eclipse projects, rather than interim/stable builds