Creating CMS prodagent releases (release management)

Last updated: January, 2009

Model:

Typically a release is specified in a set of rpm spec files. The package your building can depend on other packages that are maintained by other pakcage managers. These packages are versioned and when you build your package you have to specify which version of which package you want to use. The package dependency relationship forms a direct acyclic graph where the node at the tail of the arrow is dependend from the node at the head end of the arrow. Release versions and package dependencies can be modelled as a versioned directed acyclic graph (Figure 1). The steps for building a package are defined in this workflow.. The next sections describe some of these steps in more detail.

Figure 1. Release dependencies

Creating a Development Tag

The code developed in your project (not including all third party dependencies) is located in a cvs repository. Whenever you make a release you tag the part you want to release. The tag is usually of the format: pacakagename_major_minor_bug. E.g. PRODAGENT_1_12_10. The tag can also be augmented with various postfixes like "_PRE" for pre release, or "_INT" for integration testing. The following describes how to create a tag for your package.

When tagging the code base the easiest thing is to tag the head of the cvs repository. However not always all modules in the head are properly tested or ready. So sometimes you need to tag 'selectively'. That is you have an older release (tag) and you want to create a new release based on this older one, but augmented with the head of particular modules. releaseAnalyis.py is a utility that can help you analyze the modules that need to be selected. It takes as input the output (in a file) from the command cvs status -v, and the previous release tag. It will then list all the modules that have been updated since that release tag. This allows you to select which of the updated files you want to tag with your new tag (NOTE: as you are the package builder it is not your responsibility to select the files, developers should give you a list. Ideally this works best if they give you a tag that represents files that go into the new release. The releaseAnalysis.py file is mainly to do a rough check of what needs to go in). So first you tag the selected modules with the new release tag, then you check out the previous release and tag all these files with the new release tag. CVS will give warnings that some files already contain this tag (because you tagged their head) and ignore these. As selectively tagging can be tedious if you have more than a few modules you can use the tagFiles.py script which takes as input a list of files (that you can copy paste from the release analysis output and a tag that you want to stick on them. Be sure you execute this in the right directory to make it work NOTE: If your task is only to build this working with tags from developers greatly simplifies this process.

Creating a Build Tag

Versioning of packages is done through cvs tagging of so called rpm (spec) files which define the packages. Everytime you make a new release you would (cvs) tag the spec files and other files in COMP/CMSDIST needed to build that release. Figure 1 illustrates this: to make a release PRODAGENT_0_12_10_20090122 we want need several subpackages of a particular version. Thus we need to find all files that are tagged WEBTOOLS_0_10_1_20081203, PHEDEX_3_0_7_20090105, WMCORE_0_0_10_20081229, PRODCOMMON_0_12_20090120 and our spec file for the ProdAgent package. These files are tagged with your release tag. NOTE: beware of dependencies which share other dependencies of different versions!.

To create the build tag you can use the Python application build_tag.py. This application takes as input the config.py (make sure you set the config.sh variables) file which contains the direct sub packages of your package and their respective versions. It also contains a list of additional files that are needed by the build environment or had to be modified from the sub packages for some reason. NOTE: ideally we do not want to have to specify individual exceptions for files that are part of one of our dependencies and it should be up to the package manager of our dependencies to ensure this is fixed. When you run build_tag.py it will first generate (on the screen) a dependency tree by parsing the spec files and after that it will for each file (and additional patches) check out the correct version, needed for your release. After all files are check out you can tag all these files with your release tag.

Building the Package

Once all files are tagged you set the release tag in build_pack.sh (also changed other variables in this file as you see fit). Depending on the version you want to create (32 or 64 bit) you comment out the proper build command. When you run the script it asks if you want to modify the build configuration script. Depending if you build 32 or 64 bit you might need to edit it.

Once all is set and your ssh key is registered in the CMS repository, the package will be build and uploaded. If you have any problems during the build you need to fix them and create a new build tag. After the first error you can edit the spec files locally and run locally (see build_pack.sh file last line) until everythings builds correctly. After that you can commit the changes and create the proper tags, edit the config.py and create a new build tag.

Announcing the Tag

Send an email to the appropriate mailing lists including the new features and bug fixes. You can use the getCVSLog.sh script (on your cvs based development code) to retrieve the changes w.r.t to the previous release you announced.

NOTE: Make sure you are allowed to upload the CMS release area, give the person responsible for this your ssh key and make sure your .ssh/config file contains support for the protocol your key was generated with (e.g. "protocol 1,2").

Update the ProdAgent installation and ReleaseNotes TWiki pages:
-Installation
-Releases