Child pages
  • Software Release Checklist
Skip to end of metadata
Go to start of metadata

This page is to document the release process for the current OpSim code, but going forward to the newly refactored code, the ideas will be the same even if the actual execution will change. The person in charge of going through the checklist and executing its contents is the Release Manager.

Setting up for a Release

  1. Create a new version for the code on the JIRA board. Use whole numbers for the version number and avoid using git SHAs.
  2. Create and/or assign tickets to that version.
  3. Complete all work for the version.

During a the work on a release, the code should occasionally be run through a CI system. This has been nicely captured with the new Jenkins CI system. To register, do the following:

  1. Find the the Bot: Jenkins Demo room in HipChat and click on the link in the topic.
  2. Click the log in link on the Jenkins page and authorize your Github account.
  3. Run a build

To accomplish this last step, the following annotated picture is used.

  1. Click on the Build Parameters link
    1. This will make sure the right pane is visible
  2. Put in the branch(es) that you want to build against
  3. Specify the product name (i.e. sims_operations)
  4. Check the SKIP_DEMO button
    1. The demo is related to the LSST stack and isn't necessary for this
  5. Click the Build button and way things should go
  6. Step 5 as necessary to address any issues

Preparing the Release

  1. Create a branch for the release.
  2. Update the release notes.
  3. Update documentation for release.
  4. Execute a build via the Jenkins CI system ensure everything nominally works.
    1. See above section if you aren't using the Jenkins system yet.
  5. Execute a quick OpSim run for testing purposes.
  6. Merge the release branch back onto master using the --no-ff option.
  7. Tag the code with version number.

Build the Release

This involves having credentials as the lists user on the lsst-dev.ncsa.illinois.edu server in order to actually build the EUPS package. 

  1. Log into the server as lsstsw.
  2. Run the following command:
    1. rebuild -r <stack tag> -r <OpSim tag> sims_operations
    2. where <stack tag> is a currently used LSST stack release (i.e. w.2015.22) and <OpSim tag> is the git repo tag
  3. The build will return a build tag bNNNN (I think we're at 4 digits now)
  4. Then run:
    1. publish -b <build tag> -t <package tag> sims_operations
    2. where <build tag> was retrieved in the previous step and <package tag> is an alternate ID for the particular build.
    3. We're using a package tag of the format opsim_X_Y_Z
  5. Test to see if you can eups distrib install the new package
  6. Run a quick OpSim test to ensure things work.
  7. If super paranoid, run a longer test.

Finishing up the Release

  1. Update the documentation on the ops2 machine by running the publish.sh script in the doc directory of the source code.
    1. Make sure to checkout to the tag and run scons to update the correct version number before running publish.sh
  2. The production machines should all be updated to install the current EUPS package.
  3. All production machines need a directory in /lsst for subsequent running. It should look something like: /lsst/opsim_X.Y.Z
    1. Underneath that directory, to other, log and output, need to be created.
  4. A full 10 year simulation should be run by the Production Run Manager on every major release once the Release Manager has installed the software. 
    1. If a patch release contains a major bug fix, a 10 year simulation should be run in that case too.
  • No labels