1 / 10

D0 Releases CDF-Presentation 2/12/01

D0 Releases CDF-Presentation 2/12/01. General Strategy Weekly Production Very similar to CDF’s procedures I believe, so I’ll say very little about this. Weekly Release (General) Versions Web Release Request System Building a release Developer’s perspective Release Manager’s perspective.

melora
Download Presentation

D0 Releases CDF-Presentation 2/12/01

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. D0 ReleasesCDF-Presentation2/12/01 • General Strategy • Weekly • Production • Very similar to CDF’s procedures I believe, so I’ll say very little about this. • Weekly Release (General) • Versions • Web Release Request System • Building a release • Developer’s perspective • Release Manager’s perspective D0 Releases-Alan Jonckheere

  2. D0 ReleasesCDF-Presentation2/12/01 • General Strategy • Weekly Releases, start Monday afternoon • More or less matches most developers’ timeframe • too fast more often than too slow • Coordinated by SubSystem Coordinators • Daily “bug fix” builds • “Freeze” on Friday (but…) • Available on disk for ~3 weeks • “stable” base for development • available for remote distribution • archived after that • Production releases • Targeted at some specific executable or set of executables, sometimes all major executables. • Coordinated by Production Release Manager • different people depending on targeted executable(s) • Extensive verification. • Once “frozen” can go onto the farms and to remote production facilities. • Available on disk and for distribution for a “long” time, until superceded. D0 Releases-Alan Jonckheere

  3. D0 ReleasesCDF-Presentation2/12/01 • Weekly Releases • Versions are “rtag”d in cvs • Release requested via the Web based Release Request system • Package • Version • Release notes (not very useful usually) • Special requirements (simultaneous releases etc) • Approved by subsystem coordinator • coordinate interface changes within and between subsystems. • coordinate development • Daily builds with “bug fixes”, address only problems reported by the error mailings from previous builds that week • request via Web Release Request system • direct to release managers • coordinators are notified so can abort request. D0 Releases-Alan Jonckheere

  4. D0 ReleasesCDF-Presentation2/12/01 • Versions are “rtag”d in cvs • Allows use of cvs in the way that it’s meant to be used • Concurrent development at widely scattered sites • Can be used to “transport” code between machines • Encourages committing changes frequently, changes don’t need to be fully tested until the release has been requested • Can ask other people to test the code before release • addpkg <pkg> <tag> • rtag vs tag • PRO • rtag goes into history file cvs history -Tan <pkg> • can determine what tags exist without checking out the package. • CON • only tags the head (main trunk or branch) • tagging must precede full testing • unlikely to run out of numbers, so not a real problem. D0 Releases-Alan Jonckheere

  5. D0 ReleasesCDF-Presentation2/12/01 • Release Request Systemhttp://www-d0.fnal.gov/software/cmgt/releaserequest/ • Could be fully automated • We’ve chosen to put people into the loop at several places • Weekly (by 15:00 Monday afternoon) • Developer rtag’s packages • Developer requests release • SubSystem Coordinator approves release • Release Manager makes the final choice • pretty much all of those approved • has to beat on coordinators to approve or explain why not. • Daily Bug Fixes (by 15:00 each day) supposed to be only fixes to problems that were found in that weeks build • Developer rtag’s packages • Developer requests release (bug fix) • Release Manager makes the final choice • Most bug fixes should be because of interactions between packages, but, in fact, some developers let us do their testing for them, especially on platforms other than their main development platform. • Full history and status of requests, by package, coordinator and release is available online (Oracle db) D0 Releases-Alan Jonckheere

  6. D0 ReleasesCDF-Presentation2/12/01 • Building a Release • Developer’s perspective • newrel -t <base release> <working directory> • addpkg -h <pkg> • addpkg <pkg> (version in <base release>) • addpkg <pkg> <version> • . . . • gmake • gmake test • other tests • edit • loop • cvs commit • rtag • request release (“normal” or “bug fix”) D0 Releases-Alan Jonckheere

  7. D0 ReleasesCDF-Presentation2/12/01 • Building a Release • SubSystem Coordinator’s perspective • Talk to developers • Monday • Check for new release requests (Monday) • Make sure the requests match what the group is trying to do. • Approve requests as appropriate • Daily • Monitor SubSystem’s error logs • Push developers to supply corrections • Find someone to supply corrections • Monitor “bug fix” requests • Friday • SubSystem Coordinators’ Meeting • Participate in status discussion • Announce planned interface changes • Coordinate global changes with other coordinators. D0 Releases-Alan Jonckheere

  8. D0 ReleasesCDF-Presentation2/12/01 • Building a Release • Release Manager’s perspective • Could be fully automated • Monday • checkout skeleton • checkout release stream independent tools • checkout release stream dependent files • Allows separate release streamsUnix (IRIX and Linux)NTOnline (OSF1) • declare to ups • Chose the packages/versions to be released • Mail contains package/versions • edit “inventory” file • simply a list of all packages/versions in that release • “exppkgs.sh”, exports package/version if doesn’t already exist, declares to ups • forcepkglinks.sh, creates sym links to package/version • BldTable.sh, builds D0RunII.table • buildrel.sh, “gmake all; gmake test” with some special manipulations that we have to do. D0 Releases-Alan Jonckheere

  9. D0 ReleasesCDF-Presentation2/12/01 • Building a Release • Release Manager’s perspective • Daily (Tuesday, Wednesday, Thursday) • Bug developers/coordinators to get fixes • Help developers to interpret error logs • Point out why their package(s) failed to build • Chose the packages/versions to be released • Mail contains package/versions • edit “inventory” file • simply a list of all packages/versions in that release • “exppkgs.sh”, exports package/version if doesn’t already exist, declares to ups • forcepkglinks.sh, creates sym links to package/version • BldTable.sh, builds D0RunII.table • buildrel.sh, “gmake all; gmake test” with some special manipulations that we have to do. D0 Releases-Alan Jonckheere

  10. D0 ReleasesCDF-Presentation2/12/01 • Building a Release • Release Manager’s perspective • Friday • SubSystem Coordinators meeting • summarize release status • decide if extra builds are needed1 or 2 over the weekendall next week (rarely happens) • decide if release is too broken to save(rarely happens) • Freeze release (Friday or Monday morning) • d0freezerel.sh, freeze rcp database, freeze other data files, make tar files, install tar files on upd distribution node, declare to ups/upd. D0 Releases-Alan Jonckheere

More Related