Re: [orion-dev] Process for converging on stable/release builds

[Anthony Hunter <anthonyh@xxxxxxxxxx>]

Hi John,

The proposed process is:
 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 

We are forgetting the step:
 0. Committers push changes to
master when they believe they are production quality or have a "setting"
to turn them off.

I would then propose an improved process:
 0. Committers push changes to
master when they believe they are production quality or have a "setting"
to turn them off (same as is current process).
 1. Each successful build is automatically
promoted to orion.eclipse.org.  (same as is current process, the only
difference is that we automate).
 2. Committers test orion.eclipse.org
and raise bugs when they hit issues. (same as is current process).
 3. On Monday at 12:00 ET / 18:00
CET we access what is running on orion.eclipse.org as the GOLD build for
the week. 
 3a. If required, problems are
backed out of master, a new build is performed against the master branch
and promoted to orion.eclipse.org
 3b. Committers test orion.eclipse.org
and further builds are run as needed (same as is current process).
 4. The Monday GOLD build is promoted
as stable with the naming convention S# where # is the sequential stable
build number since start of the release cycle 

This improved process is awesome because:
a. We are all developing and testing
everywhere on one common branch, master, this is keeps things simple.
b. We have one build against one stream,
simple.
c. We do not introduce the work of an
Integrator reviewing changes and creating separate branches. simple.
d. We have increased awareness that
Monday's build is the target GOLD build so there is less chance of unintegrated
code in master on Monday morning, simple.
e. We have increased awareness that
integration testing is best done by pushing on Tuesday rather than Friday/Monday
without needing new branches, builds and work, simple.
 
Cheers...
Anthony




From:      
 John Arthorne/Ottawa/IBM@IBMCA
To:      
 orion-dev@xxxxxxxxxxx
Date:      
 2014/07/17 01:44 PM
Subject:    
   [orion-dev]
Process for converging on stable/release builds
Sent by:    
   orion-dev-bounces@xxxxxxxxxxx

---

During Orion 7.0 we have completely
stopped doing milestones in favour of a more continuous delivery model.
We would like to produce regular (roughly weekly) stable builds that can
be deployed to orionhub.org. One issue with this is how to stabilize the
code for a stable build without disrupting ongoing development in master.
After discussing ideas with various committers I would like to propose
a process of branching once per week at a predictable time, and use that
to converge on a stable build while allowing master branch to continue
development. 

https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process

I have done a test drive of this process this week. I setup new "stable"
build in Hudson that builds from a branch: 

https://hudson.eclipse.org/orion/job/orion-client-stable/

I used this to produced a stable 7.0 S1 (Orion 7 stable build #1) that
I have deployed to orionhub.org: 

http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html

Committers please take a look at this proposed process and respond here
with any thoughts and concerns. 

Thanks, 
John _______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev