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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Hey Anthony,

The "no branch" approach is
good in theory but in practice it can sometimes take a day or more to produce
a stable build, and in the meantime we would either need to ask everyone
to stop pushing to master, or live with new changes continuing to arrive
while trying to stabilize. Reverting changes in master is also disruptive
for committers. While we can strive to only push production quality code
into master, in reality I don't think we have enough test automation to
be confident enough that this will always be the case.

I would like to try the branching approach
for awhile and see how it goes. We can re-assess after a couple of months
and see how it is going. My hope is that apart from the person doing the
integration this process will be relatively seamless and non-disruptive
for committers...

John




From:      
 Anthony Hunter/Ottawa/IBM@IBMCA
To:      
 Orion developer discussions
<orion-dev@xxxxxxxxxxx>, 
Cc:      
 orion-dev-bounces@xxxxxxxxxxx
Date:      
 07/17/2014 03:53 PM
Subject:    
   Re: [orion-dev]
Process for converging on stable/release builds
Sent by:    
   orion-dev-bounces@xxxxxxxxxxx

---

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
_______________________________________________
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