Release workflow

To signal the start of a new release, a release branch must be made.

To commit to a release branch see here.

Naming

Autoreduction releases are currently named inline with the upcoming cycle at ISIS. e.g. if the next cycle at ISIS is cycle_20_1 then the autoreduction release will be named Autoreduction-v20.1

Schedule

Autoreduction software releases are currently in coordinated with ISIS facility cycles. We aim to release the most up to date version of the code base 2 weeks before an ISIS cycle starts and then have this solution deployed and tested on the production environment 1 week before the start of the cycle. The following steps that must take place during a release are, written in chronological order heading towards a release:

Starting 2-3 weeks before cycle start

1. Inform development team

Let the development team know that a release branch is being created

2. Release branch

This should be created from the current state of master and follow the naming convention defined above(git checkout -b Autoreduction-v20.1. The first commit should be to update the version number of the software by incrementing it in the setup.py file.

3. Identify the key issues for the release

Assess the remaining 'in progress' issues in the repository and evaluate if they are critical enough that they must be in the release. Try to be strict with this decision as waiting for additional non-critical features to be developed could slow down the release process. Move all non-critical issues into the next sprint project and leave any critical issues in the current sprint.

4. Resolve remaining issues

Ensure that all team effort goes into resolving the remaining critical release issues where possible. These issues should be the top priority for all team members to complete. When these issue are complete they should be merged with the release branch.

5. Smoke testing on development

Once all critical issues are merged, the release branch should be placed onto all development nodes and tested inline with the smoke testing documentation. Any issues that arise from this should be raised as git issues, if any of these issues are deemed critical then return to step 4.

6. Smoke testing on production

The release branch should now be pulled onto all the production nodes and smoke tested there. Like step 5, any issues should be raised, and if critical, resolved.

7. Customer validation

When the production smoke testing is complete or during this smoke testing, customers are invited to participate in help with testing, where they will be able to test all aspects of the service not reliant on ISIS being in cycle. Prior to jobs with be manually submitted to enable customers to rerun reduction jobs etc.

8. Release

Once all of the above steps are complete, we are ready to release.