Skip to content

Creating a release

Jump to bottom Edit New page
Lilith Cole edited this page Aug 15, 2022 · 149 revisions

Wiki > Deployment > Creating a release

Understanding Java Licensing

Make sure you understand how Java is licensed, so that we do not inadvertently make ISIS liable for licensing fees.

Release tickets

Text for release ticket:

As a developer I want an IBEX release so I can install it on the instrument machines for the start of machine physics on 26th.

Acceptance Criteria:

- [ ] [Pre Testing Steps](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Creating-a-release#pre-testing)
- [ ] [Testing steps](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Creating-a-release#testing)
- [ ] [Post Testing](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Creating-a-release#post-testing)
- [ ] [Create a ticket to update dependencies to latest versions and test](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Dependency-updates)
- [ ] [Create a ticket to give instrument demos](https://github.com/ISISComputingGroup/IBEX/wiki/Timetable-for-Instrument-Demos)
- [ ] Distribute release notes via email [Instrument scientist release email](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Updating-Instrument-Machines#a-new-release)

Standard Release

Project is ready to be released not for a specific event, e.g. at the end of a sprint. Script Generator version number always differs to the client's.

Pre Testing

  1. Contact computing group to let us know of the upgrade. Find out anything that needs to be in the release that isn't and mark with for release label. (This does not prevent a release)

  2. Look at the released features in this branch Upcoming Changes and find the most significant level of change (i.e. is this cumulatively a major change, a minor change, or a patch?).

  3. Update the upgrade script to include the latest version (this is done on master). Steps to do this are in Config Upgrader in section creating a production upgrade script

    1. After committing these changes to master on the EPICS-upgrade submodule, don't forget to push the new submodule version to master on the top EPICS branch. This is needed to make sure you changes appear on the release branch created in the next step.

  4. Start a release branch so that the code is frozen (e.g. Release_1.1.0). You will need a branch for

    1. genie_python

    2. ibex_gui

    3. script_generator

      1. Script generator release branch should start with Release_Script_Gen_X.x.m

    4. EPICS

    5. For EPICS submodules you should use:

      1. git submodule update --init --recursive --remote which sets all the repos to their latest version
      2. git status and check if any submodules are listed as new commits. If this is so, it means a new submodule version has not been pushed (the EPICS repo checks Jenkins build will likely be in error). Normally this module should be pushed and once the repo checks build passes this step repeated. If you do not want the changes in this submodule, then you will likely need to checkout a desired commit on the top level and then do the above submodule update without --remote. See advice if this doesn't make sense.
      3. git submodule foreach "(git checkout -b Release_X.x.x; git push -u origin Release_X.x.x)||true" this creates a branch at the current checked out version for each repo and pushes it.

    6. JSON_bourne. First check if changes have been made as JSON_bourne is rarely edited.

  5. Update the version numbers:

    1. GUI

      1. In /uk.ac.stfc.isis.ibex.e4.client/plugin.xml in Overview tab set Version: to be X.x.m
      2. In /uk.ac.stfc.isis.ibex.e4.client/pom.xml add or edit a <version> tag after the parent block (do not edit in parent, leave the version there as 1.0.0-SNAPSHOT) to have content to be X.x.m (This tag may not be present and so will have to be added see as in this example)
      3. Edit the Bundle-Version in /uk.ac.stfc.isis.ibex.e4.client/META-INF/MANIFEST.mf to be X.x.m

    2. Script generator

      1. In /uk.ac.stfc.isis.scriptgenerator.client/plugin.xml in Overview tab set Version: to be X.x.m
      2. In /uk.ac.stfc.isis.scriptgenerator.client/pom.xml create a new <version> tag (not in parent, just after its closing tag) and give it content of be X.x.m (e.g. see here)

    3. EPICS

      1. In EPICS\ioc\master\INSTETC\INSTETC-IOC-01App\Db\svn-revision.db.tmpl edit field(VAL, "0.0.0.$WCREV$") to be field(VAL, "X.x.m.$WCREV$")
      2. NB this has to be committed on a branch in IOC and then this submodule commit has to be added to the EPICS release branch

    4. Genie Python

      1. ...\Python\Lib\site-packages\genie_python\version.py edit VERSION = "0.0.0.qualifier" to VERSION = "X.x.m"

  6. Commit your changes and push.

  7. For the builds ibex_gui_release, genie_python_release, scriptgenerator_release and EPICS_release, do the following:

    1. Find the release build pipeline in Jenkins
    2. Click "Scan repository". It should find the new release branch and queue a build.
    3. The release build for script generator will be created in P:\Kits$\CompGroup\ICP\Releases\script_generator_release\X.x.m
    4. The release builds for the rest will be created in P:\Kits$\CompGroup\ICP\Releases\X.x.m

  8. Check that all of the merged tickets have also had their release notes merged then move the changes which have been merged into the release from the upcoming page to a new release notes page for the version. Whilst doing this make sure that the release notes are as understandable as possible.

  9. Create a released version in the releases table (including link to release notes)

  10. Update the "latest stable release" link on the IBEX wiki homepage

  11. Find dependencies which have been updated since last release and add them to the bottom of the release notes. Particularly make sure that you run a pip freeze on a cleanly released genie_python to give you the python dependencies list.

  12. Update the user manual with any relevant changes

Testing

One or more people should do manual system tests, using this page.

Post Testing

These steps should only be done once all changes to a release have been made and we are ready to deploy. Here we are creating a tag which will become inconsistent if further changes are made to the release branch. Hence it is important to delete the relevant release branch after it has been tagged.

  1. Create a release tag in the EPICS, ibex_gui, genie_python and JSON_bourne repositories. For each repo

    1. Go to [REPO_URL]/releases, e.g. https://github.com/ISISComputingGroup/ibex_gui/releases
    2. Click Draft a new release
    3. Enter the tag version in the format vX.x.p and target the release branch
    4. Enter the title Release version X.x.p
    5. Add a link to the release notes in the description
    6. Delete the release branch once the release and tag has been created.

  2. Create release tag from the release branch for each submodules in EPICS, then delete the release branch. To do this, run the following two git commands in top level EPICS (replace X.x.x with the release number):

    1. git submodule foreach --recursive "git fetch && git tag Release_ibex_X.x.x origin/Release_X.x.x || exit 0" // Create tag
    2. git submodule foreach --recursive "git push --tags && git push -d origin Release_X.x.x || exit 0" // Push tags and delete release branch

    Note: you may need to run git config fsck.badEmail ignore for the above step

  3. Make sure any changes on the release branch are merged back onto master (except version numbering)

  4. Consider which instruments need this release:

    • Breaking release: upgrade everyone
    • Big improvement: upgrade everyone if there is a big improvement that everyone will benefit from
    • Standard release: upgrade instruments that need updates, i.e. they need a newly released feature, and all those that are in the current release group, see column in instruments table. Note on the release ticket which instruments need to be released to using checkboxes (one for start and one for finish).

  5. Deploy a new JSON_bourne if required see here

Partial Release

For any release in which GUI version increments but server version does not, ensure the previous server version is added to the release folder via symbolic links or junctions, see this ticket.

Patch Release

The is a release when a change needs to be made between standard releases; i.e. a standard release is inappropriate because it includes lots of code which has not been through a code freeze and test.

  1. Follow all Pre Testing steps above except:
    • For step 4 (creating the release branch) instead of creating from master create it from the latest release tag
    • Update GUI Java JRE
    • Finding the most significant change
    • Updating the MySQL and Java being deployed
  2. Is the code for the bug/enhancement already written?
    • No: Make the changes on the branch.
    • Yes: Cherry pick commits needed from the branch with the written code
  3. Test
  4. Release as per a standard release but
    1. Use this branch instead of master
    2. Only include the change you have made in the release notes
    3. Copy the release notes issues into the development page
  5. Merge the new code back into master

Adding late commits to the release Branch for EPICS

  1. Test and merge the change into master
  2. Create a release branch in the submodule (if it doesn't exist)
    1. Navigate to EPICS in github
    2. navigate to the submodule
    3. Create new branch (this means it will be branched from the release point)
  3. Switch the branch of the submodule: git checkout Release_X.x.m
  4. Pull the latest release branch: git pull
  5. Merge in the ticket git merge XXX
  6. push that branch
  7. cd to EPICS
  8. checkout release branch and pull
  9. update submodule reference, commit and push.
Add a custom footer
Add a custom sidebar
Clone this wiki locally