Preproduction Release Check List
Introduction
The following list must be used in combination with the
Integration Procedure twiki that describes all the technical details involved in the release process. This twiki aims to list the necessary steps to create a preproduction release helping to avoid mistakes and decrease human errors.
Check List template
Please, print the following check list templates to go through the production release process:
Pre requirements
The following machines are needed in order to do a production release:
- glite 3.1, 32bit: SLC4/32bit repo machine with glite-release CVS module, mysql-server and mysql client installed.
- glite 3.1, 64bit: SLC4/64bit repo machine with glite-release CVS module, mysql-server and mysql client installed.
- glite 3.2, 64bit: SL5/64bit repo machine with glite-release CVS module, mysql-server and mysql client installed. Remeber to install also your GPG key to sign rpms.
Check List
1.
cd glite-release
in your repo machine and run
cvs update
to make sure you have the last version. Make sure that in
config.sh
,
GLITE_RELEASE
contains the right value of the release you are doing.
2. Check the prepare area is equal to the pps one. Use the
check_pps_all
script for this. Otherwise delete the current prepare area and copy from pps:
cp -pR /afs/cern.ch/project/gd/www/glite/pps/3.x /afs/cern.ch/project/gd/www/glite/prepare/pps/3.x
3. Make sure the previous pps release was properly tagged in CVS. You can do this by checking that the last version of each metapackage in the pps list is tagged in CVS. If not, run the following scripts which wil tag the prod-lists, where NN corresponds to the previous update:
./scripts/list-updated-components -r pps -u NN -p arch
./scripts/make-release -l updateNN.pps -p arch -g
4. If you've done the tag, commit the
updateXX.pps
file from the previous release into
glite-release/update_files/pps/platform
.
5. Query Savannah for the patches which are
Certified
. Note that at this point you should also check all the previous production releases that may have happened before this pps release. If there were fast tracked patches, those patches should also be included in this pps release.
6. For each certified patch:
- Check that the patch you want to move to PPS doesn't contain any dependency to uncertified patches. If it's the case, the patch shouldn't be included in the PPS release until all its dependencies have been certified.
- Check in the list of associated bugs, if any, that the bug status is
Fix certified
or Fixed not certified
. Contact certifiers if there are bugs in Ready for test
since they should update the status after verifying the bug.
- At this point the Release notes should be in good shape but double check again and ask for an improved text to the patch submitter if the quality is poor or the explanations are not very useful.
- IMPORTANT Make also sure that in case there are metapackage changes, the pps-lists should reflect the correct package list with the added or removed rpm.
7. At this point search in Savannah for all the patches whose
PPS Release
field is
3.1.0 PPS Update NN
. Double check that
you don't forget any patch you would like to release!
8. Create the
updateNN.pps
file:
scripts/list-updated-components -r pps -u NN -p <platform>
The syntax of this file is:
metapackage-name|old-cvs-tag|old-cvs-version|new-cvs-tag|new-cvs-version| UPDATE |
9. Check the
updateNN.pps
file:
scripts/print-release updateNN.pps <platform> check
Only the metapackages that may have dependencies on rpms that change in this release should appear. This is difficult to track when the release contains several patches but it's good to do some extra checking at this point. Get familiar with the patches and with the affected metapackages and try to detect some inconsistencies.
10. Make the Release. In 3.1, if there are new node types, then create a symbolic link to the generic folder in the prepare area.
If you don't want to tag the release at this point, please run the command with the option
-s
.
scripts/make-release (-s) -l updateNN.pps -p <platform>
You can compare whether the result of running this command is what you expect by using the
check_pps_all
script. It compares the prepare area with pps and tells you the differences. It's necessary to compare the listed rpms with the rpm lists in the patches that are part of the update. It requires some manual checking.
11. Create the Tarballs. Send a mail to Ricardo and Andreas like this one:
Remember that in PPS we only create the TAR UI.
Subject: UI Tarball for gLite 3.X Update NN to PPS
Body:
Hi Ricardo, Andreas,
* PPS UPDATE <NN> *
For gLite 3.1:
32BIT
====
PPS-glite-UI-<NEW UI-Version> here:
http://grid-deployment.web.cern.ch/grid-deployment/glite/prepare/pps/3.1/glite-UI/sl4/i386
For gLite 3.2:
64BIT
====
groupinstall for http://grid-deployment.web.cern.ch/grid-deployment/glite/prepare/pps/3.2/glite-UI/sl4/x86_64
groupinstall version marker for the UI/64:
glite-UI-version-<NEW 64 UI-Version>
Happy tarballing !!
Thanks!
12. Generate the Release Notes.
13. When the tarballs are ready, copy the pre-production release from the prepare area:
cd /afs/cern.ch/project/gd/www/glite/pps
rm -Rf 3.1_old
cp -pR /afs/cern.ch/project/gd/www/glite/prepare/pps/3.1 \
/afs/cern.ch/project/gd/www/glite/pps/3.1_UXXPPS
ln -s 3.1_UXXPPS 3.1
14. Modify the release date in the general
PPS Release Notes page and in the page relevant for this update. Also consider to remove links to previous updates in the general page.
15. For each release patch change the Savannah status to "In PPS deployment test".
16. Announce the release to PPS. The mail should be something like:
The announcement is usually a mail reply to a GGUS ticket created by PPS Team with the list of patches which should go to PPS. The mail should be addressed to: pps-support (PPS Coordination); pps-deployment-test;
helpdesk@ggusNOSPAMPLEASE.org; pps-apt-repository-update.
A template for answering this mail :
Dear all,
The gLite 3.X.0 PPS Update NN is ready. Please find related information here:
https://twiki.cern.ch/twiki/bin/view/EGEE/PPSReleaseNotes_3X0_PPS_UpdateNN
Cheers
17. Remove from
/afs/cern.ch/project/gd/www/glite/cert/3.1/patches
all patches released in this update.
--
MariaALANDESPRADILLO - 22 Jan 2009