Difference between revisions of "Build and Release Process"

From Eclipsepedia

Jump to: navigation, search
(Nightly Builds)
(Build and/or Test Results)
Line 37: Line 37:
 
* Checkins, other than to fix broken builds and tests, are frozen until the builds and tests pass
 
* Checkins, other than to fix broken builds and tests, are frozen until the builds and tests pass
 
* Check the results of the nightly runs before checking in
 
* Check the results of the nightly runs before checking in
 +
 +
(Comment: I think the new mailing list is a good idea)
 +
 
==Weekly Promotion to <nowiki>’</nowiki>Good Build<nowiki>’</nowiki> & Upload to Eclipse==
 
==Weekly Promotion to <nowiki>’</nowiki>Good Build<nowiki>’</nowiki> & Upload to Eclipse==
 
* Once a week the steward will pick a build towards the end of the week (Thursday evening/Friday morning typically) that has built clean and passed the minimum acceptance tests to promote to <nowiki>’</nowiki>good build<nowiki>’</nowiki>.
 
* Once a week the steward will pick a build towards the end of the week (Thursday evening/Friday morning typically) that has built clean and passed the minimum acceptance tests to promote to <nowiki>’</nowiki>good build<nowiki>’</nowiki>.

Revision as of 08:29, 14 June 2007

Contents

Daily Builds & Tests

Ownership

  • Anyone who ever checks anything in (that is all committers) are generally responsible for clean builds and tests.
  • Clean daily builds and tests keep the system stable, prevent regressions, and avoid down time.
  • Anytime you check something in you are specifically responsible for monitoring the builds and tests until they pass.
  • That means that for at least 24 hours after your checkin you are available, responsive and prepared to help with any issues that crop up.

Stewardship

  • On a rotating basis some human who can access the build and test machines, and is an Aperi committer, will be responsible for seeing to it that the builds and tests run to completion.
  • In the event of problems with the build & test system itself they are expected to resolve them as soon as possible and get the build and test restarted
  • In the event of problems with the build caused by developer checkins they are expected to follow up with developers to ensure fixes are made quickly, and then get the build and test restarted.

Q: will a bugzilla be opened for each problem

Nightly Builds

  • Every 24 hours at GMT-8 10:00 PM (PDT) the state of the HEAD branch of the CVS repository will be labeled with a time stamp
  • The time stamp will be encoded with the release number, date, time, and serial build number: Aperi-RM.m-YY:MM:DD:HH:MM:SS-NNNN
  • A module list will be maintained (in CVS) that list all the modules that are part of the current build, labeling and extracting will be restricted to those modules. This could be a PDE build style map file or .pfd file. This map file will be named Aperi-RM.m.{map|pfd} and will be labeled with the time stamp at build time as well.
  • The source will be extracted based on that time stamp and the system will be built.
  • Build results (install files, and any other artifacts) will be archived, but will not be uploaded to the Eclipse download site (Q: Does this mean they will be archived in cvs?)
  • The build artifacts will have the build time stamp embedded in the name
  • The GUI ’about’ and server version #’s will have the build time stamp embedded
  • Every runtime log file should have the build time stamp embedded in it as well

Nightly Tests

  • If/when the system is successfully built the install bundles will be automatically copied to prepared test systems
  • The prepared systems will automatically run a test install and minimal acceptance test
  • One each for Derby and DB2 on each platform Windows and Linux
  • Each test Install/run should be less than 60 minutes to keep turnaround time reasonable

Build and/or Test Results

  • Results of the nightly build will be emailed to a new email distribution list ’aperi-builds@eclipse.org’
  • The email will indicate the time stamp, and the SUCCESS or FAIL of the build
  • The tail of the build log or the portion of the build log that contains build failures will be embedded in the body of the email.
  • Results of the nightly tests will be emailed separately, one for each test system, to ’aperi-builds@eclipse.org’
  • The email will indicate the time stamp, and the SUCCESS or FAIL of test
  • Upon failure a zip file of the relevant logs will be attached to the email.
  • In addition all results, and logs will be posted on a public web/wiki for your browsing convenience.
  • Checkins, other than to fix broken builds and tests, are frozen until the builds and tests pass
  • Check the results of the nightly runs before checking in

(Comment: I think the new mailing list is a good idea)

Weekly Promotion to ’Good Build’ & Upload to Eclipse

  • Once a week the steward will pick a build towards the end of the week (Thursday evening/Friday morning typically) that has built clean and passed the minimum acceptance tests to promote to ’good build’.
  • The good build will relabeled in CVS with the ’Aperi-RM.n-GOOD’ label. There is only one such label. It just gets moved for each promotion.
  • Thus, a casual user can easily find the source for the latest good build.
  • The build artifacts of the promoted build will be uploaded to the Aperi download site and the ’Latest Good Build’ link updated.
  • Thus, a casual user can easily find the install bundle for the latest good build

Milestone Releases (MS)

  • Spaced out more or less evenly across the release schedule will be milestone releases.
  • Milestone releases contain complete DCUT (code complete, unit tested) increments of functionality (they are a subset of the full functionality of the target release).
  • Milestone releases are number RVM.m.MS1 through RVM.n.MSn (R0.4.MS2 for example).
  • MSn is the last milestone release and as such contains all the functions (albeit largely untested) targeted for the full release.
  • A milestone release is created simply by relabeling and renaming a GOOD build, updating the downloads page and sending out an email saying such and such MS is available. The contents of the MS are determined by the project schedule.
  • Thus, a casual user can look at the download page and find latest milestone release

Release Candidates (RC)

  • In the end game of the project we will reach a point where all test have been run, bugs fixed, and the builds are stable
  • At that time we will promote a GOOD build to a release candidate build (would the name GA candidate be less confusing?)
  • Release Candidates are number RVM.m.RC1 through RVM.n.RCn (R0.4.RC7 for example).
  • The procedure for creating a release candidate is pretty much the same as for milestone releases: relabeling and renaming a GOOD build, updating the downloads page and sending out an email saying such and such release candidate is available.

GA Builds (GA)

  • We haven’t yet decided what the criteria is to promote a release candidate to GA, but when we do the procedure will go like this:
  • The procedure for creating a GA is pretty much the same as for milestone releases: relabeling and renaming an RC, updating the downloads page and sending out an email saying such and such GA is available.