"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

SISSVoc Release Procedure

Overview

Target audience - people making an SISSVoc release

The release procedure can be broken down into a few main phases, building a release candidate, internal testing, public testing and release.

Building a release candidate

Components - What does SISSVoc encompass?

Sesame Server - Database which contains the Vocabularies.

Elda Web Application - Implementation of Linked Data API.+

Configurations - pre-configured Elda files, landing page, CSS and stylesheets.

Time frame - Ideally you want to be doing this at a minimum 2-3 weeks before release.

This first thing to do is to create a JIRA issue for your release. This issue will be updated with links to releases + information about bugs that popup during testing.

In this phase you are simply identifying which version of Elda and Sesame is at a point that is feature complete for a particular version. This means that every feature/fix you wish to include in the release is complete or in the process of peer review. Any half finished features that are not going to be included should be disabled.

Sesame

Sesame Server and Workbench - Identify which verison of the Sesame server to use.

ELDA

The process of building involves using our build system to build this new release branch. This is done by visiting our SISSVoc Project (ensure you are logged in) and selecting 'Build Now'. The resulting files will be archived at https://cgsrv1.arrc.csiro.au/swrepo/.

The release candidate should be deployed to our test instance (not dev or release). SISSVoc RC Builder

Additional Configurations

Elda Configuration - Ensure the document is up to date.

Internal testing

Time frame - Ideally you want to be doing this 2-3 weeks before release

In this phase you are identifying any broken functionality across all supported browsers by going through the queries in basic template. This process will normally flush out any errors that should be logged as subtasks/children of the JIRA release issue (created in previous phase). Any small bug that a user could stumble across should be found in this phase, when we go to public testing it's to identify issues with usecases/workflow NOT to pickup "cosmetic" issues.

New release candidates will have to be periodically built and redeployed to the test server - SISSVoc RC Builder

You are ready to move to the next phase when the queries in basic template pass.

Documentation

Time frame - at least 1 week before release

In this phase you want to make sure that all release documentation is current

Announcing public testing

Time frame - at least 1 week before release

In this phase you will be announcing a public test release of the SISSVoc and inviting externals to test and comment on new/existing functionality.

This announcement should be made to

Template email

Hi All

The latest version of the SISSVoc <VERSION_NUMBER> has passed our internal testing procedures and is now available for public testing/comment. You can find this new release candidate at <TESTING_URL>.

We are encouraging everyone to try out the new functionality and comment on the changes. If you have any feedback or concerns then we encourage you to contact the SISSVoc team at cg-admin@csiro.au. Pending user acceptance the SISSVoc release date is scheduled for <RELEASE_DATE> which means if you'd like us to act on your feedback for this release then we will need to receive it before that date.

Summary of changes:
  • <SUMMARY_OF_CHANGES - keep this high level, no need to reference specific JIRA issues>
and of course, numerous bug fixes.

The full set of release notes can be found here at https://www.seegrid.csiro.au/wiki/Siss/VocabularyServiceInterface

For further information please contact us, cg-admin@csiro.au

Regards,
<YOUR_NAME>

Public Testing

Time frame - week prior to release

In this phase you will be receiving feedback from stakeholders/interested externals. All feedback must be logged in JIRA (children of release issue or seperate issues) and either:
  • Acted upon immediately - small fixes/bugs;
  • Scheduled for future release - larger chunks of work;
  • Closed as a 'Wont Fix' - anything outside the scope of the SISSVoc;
Whatever the resolution for a piece of feedback the external party should be kept in the loop about what is happening.

During this phase it may turn out that there is pressing need to rework large sections of the SISSVoc, in this case you can either:
  • Reduce the scope of this release;
  • Delay the release;
Once again the public should be informed of any changes.

Release Acceptance

Time frame - at least 24 hours before release.

In this phase you need a sign off from component/project lead that release is ready to proceed.

Release

Time frame - day of release

Outage Notification

Mailing List

cg-admin@csiro.au

Email Template

There will be an outage starting at 2012-MM-DD HH:MM AWST, which will last approximately 30 minutes.

Affected Services:
  • SISSVoc
Reason for Outage: Installation of the new 0.0.0 SISSVoc release.

Contact Information: If you have questions concerning an interruption in service, contact the SISS support team via one of the channels:
Email: ........@csiro.au
Phone: (08) .............

Test the release

Test the release by deploying it. Deployment guide can be found here.
Topic revision: r16 - 28 Feb 2012, JacquelineGithaiga
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).