Production 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 production release helping to avoid mistakes and decrease human errors.

NOTE The following steps must be followed in both 32bit and 64bit machines. Check for the patches to be release which platforms are affacted.

Check List

1. Make sure the previous production release was properly tagged in CVS. You can do this by checking that the last version of each metapackage in the production list is tagged in CVS. If not, tag it by increasing the version. The version should be the same one as the last version published in the gLite web pages for each metapackage.

2. Read carefully the mail sent by PPS announcing a new production release. In the mail, you'll have the information about the update number and the list of patches that should be moved to production.

3. Before working with glite-release in CVS in your machine, run cvs update to make sure you have the last version.

4. For each patch in the mail:

• Move the patch into production:

  ./scripts/move-patch -s prod PATCHNUMBER

• Check the metapackages affected by the patch have included the updated versions of the relevant rpms. Only the affected metapackages listed in the patch should change:

  cvs diff prod-lists/*

• Commit the changes to the production list:

  cvs commit -m "Applied patch #PATCHNUMBER prod-lists/<platform>*

• Mark the Release field in the corresponding Savannah patch with

  3.1.0 Update <b>NN</b>

5. At this point search in Savannah for all the patches whose Release field is 3.1.0 Update NN. Double check with the original PPS mail that you don't forget any patch!

6. Create the updateNN.prod file:

scripts/list-updated-components -r prod -u NN -p <platform>

7. Check the updateNN.prod file:

scripts/print-release updateNN.prod <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.

8. Make the Release:

 scripts/make-release -l updateNN.prod -p <platform>

It's important to check that the relevant rpms have been properly copied in each affected metapackage directory in /afs/cern.ch/project/gd/www/glite/prepare/prod/3.1/.

9. Copy the production release from the prepare area:

cd /afs/cern.ch/project/egee/gLite
rm -Rf R3.1_old
cp -pR  /afs/cern.ch/project/gd/www/glite/prepare/prod/3.1 R3.1_new 

10. Generate the Release Notes:

• You need a clean machine with org.glite.integration.release module from CVS. It contains the necessary scripts to create the release notes.
• Export the patches in Savannah by querying for 3.1.0 Update NN in Savannah Patches Export. This takes a while. Note that this is a funny tool. To make sure you get the proper xml file, select the preproduction query form and only fill in the Release field to search for 3.1.0 Update NN.
• Download the Savannah export file in the machine and reformat it if needed. Normally you need to manually add special headers like:

     <custom_text_area_9>
     &lt;h5&gt;List of affected metapackages separated by comas&lt;/h5&gt;
     </custom_text_area_9> 

• Generate the release notes (this takes a while in 32bit due to the high number of node types) by using:

     ./createReleasePages.sh --date=dd.mm.yyyy --gliteRelease=3.1 
     --update=NN --patchFile=exportedfile; --priority=Normal

11. Upload the Release Notes in the web server by running:

 
   ./scripts/uploadReleaseNotes.sh --gliteVersion=3.1 --user=CERN\\glbuild

12. Apply manual modificiations to present the information in a coherent away. In particular:

• Main page for 32Bit and main page for 64Bit
  • Check that a summary for each patch is present.
  • Check the summary for each patch reflects the highlights of the patch and that contains a list of affected metapackages.
  • Check the list of patches is complete according to the original mail sent by PPS.
  • Check if the new service packages reflect the output from print-release updateNN.prod.
  • Manually add an introduction comment like:

   This update contains multiple bug fixes in various areas. Please see below for a 
   summary of the released patches, a list of the  patches and the service update 
   table linking to each individual servide update containing specific information.

• Service specific update page relevant to the current release. Check the release notes make sense for the service and add any useful information like Known issues from PPS, etc.

12. Send mail to sa1-release-test. They'll check that everything is OK and they'll give the green light to publish the release. The mail should be something like:

Dear all,

please find a preview on the production release notes here:
http://glite.web.cern.ch/glite/packages/R3.1/updates_new.asp
http://glite.web.cern.ch/glite/packages/R3.1/x86_64/updates_new.asp

To get the details of the update, please use "Details" in the service node listing. 
You will not see any update on the service node main page.

The corresponding RPM packages can be found here:
http://linuxsoft.cern.ch/EGEE/gLite/R3.1_new/
(this location will be renamed when the update is officially released)

Any input/feedback provided as a reply to this mail would be valuable and is therefore welcome. 

Cheers,
The integrator

13. Publish the new repository (every 30min past full hour glitesoft is synchronized):

cd /afs/cern.ch/project/egee/gLite
mv R3.1 R3.1_old
mv R3.1_new R3.1

14. Publish the release notes by executing /mnt/glite-repository/packages/3.1/publishRelease.sh

15. Reply to PPS mail containing the patches to go to production

16. Announce the Release using the CIC portal.

-- MariaALANDESPRADILLO - 15 Jan 2009