To prepare a new FESA3 release for installation @GSI a couple of issues should be considered. This cook book summarizes the steps to help avoid "Fry moments".
3rd Party Libraries
Make sure the desired versions of 3rd-party libraries for the middleware (CMW) (-> CSCOSV)
Make sure the desired versions of 3rd-party libraries for WR based timing are available (-> CSCOTG)
Check with HaraldBraeuning whether Fesa Explorer ("FEX") requires an update
Framework Sources
synchronize the FESA frameworks sources in the trunk of the software repository with a released FESA3 version from CERN (helper script: fesa-tools/scripts/fetchFesaFWKTagCERN.sh)
adjust the GSI features to the current state of the core part
checkout the content of the release branch in a dedicated workspace
update the version numbers in Makefiles, fesa-model-gsi/src/xml/utility/shared-gsi.xsd if not done yet by the script createReleaseBranch.sh
perform all the changes required for the release in the release workspace and keep the branch synchronous
build and run the tests for the framework
RPM Installation
prepare the installation files in fesa-tools/installer/specs, e.g. by using the script fesa-tools/scripts/prepareInstallationFilesForNewRelease.sh
update the scripts in the get sources section of fesa-tools/installer/getSources
secure copy the installation files to the virtual machine where the release is prepared, e.g. by using the script fesa-tools/scripts/copyInstallationFilesToVM.sh
login as rpmbuild on the virtual machine, cd to /home/rpmbuild/getSources/fesa
fetch the sources from the release branch by using the scripts get_fesa_sources.sh and get_fesa-explorer_tarball.sh
cd to /home/rpmbuild/rpmbuild/SPECS and run the script build_fesa_rpms.sh. This script builds the RPM packages and installs them in the required order.
build errors will be displayed on the command line
if the whole build was successful the installed RPM packages will be listed in the end
FESA Eclipse Plug-In
synchronize the plug-ins sources with the CERNs code base
make sure the functionality so far as well as the specific functionality by GSI is still working as expected
if the plug-in has to be adapted for a new FESA3 release work in a workspace directly on the virtual machine where the release is prepared, consider working in a branch
prepare a new release of the Eclipse plug-in
Dependencies
database: inform CSCOSV about the planned release so the new version can be prepared in the FESA database
Testing
update the integration tests for the new release
run the integration tests and observe the results
test the whole installation, for inspiration see FESA3TestPlan4xx. These are the things that should work at least. Extend the list for new features or missing items to test.
WIKI
prepare a new set of accompanying wiki pages for the new release
update and add the information where necessary
Installation
ask CSCOIN (JuergenWeis or ChristophHandel) to install the new FESA3 release on a single machine of the asl cluster first
run the post installation script to upload the documentation, create the required export directories, copy the configuration files
provide a new version of the FESA3 plug-in, especially if new migrators for updating to the new FESA3 release are required
test the installation, invite early adopters (e.g. HaraldBraeuning)
on success, contact CSCOIN for a cluster-wide installation * maybe again: run the post installation script to upload the documentation, create the required export directories, copy the configuration files
At the End
merge the changes from the release branch back into the trunk (procedure: use a clean working copy of the trunk, Team>Merge... and select project in the release branch, Accept changes, commit to the trunk)
create a tag of the released FESA3 version, e.g. using the script fesa-tools/scripts/tagRelease.sh
create a tag of the release Eclipse plug-in version, e.g. by using the script fesa-plugin-scripts/uploadAndTag.sh