Who authorizes software releases?

Each release is authorized by a representative from Ocean Networks Canda (ONC) System Adminstration team, the ONC Software Development team, ONC Data team, and the Director of User Engagement.

What validation procedures are completed prior to release?

 The Software Development team at ONC employs a comprehensive process to authorize, execute, verify and communicate software releases within an Agile Scrum methodology. We utilize many tools to ensure quality and provenance: Atlassian JIRA^TM and Confluence^TM for planning tracking, documentation, etc., SVN and GIT for software versioning, Alfresco for corporate documentation, and more.

To complete a release and sprint cycle, the steps can broadly be summarized as follows: 

• Code standards are enforced with build plug-ins (checkstyle, find bugs, j-lint, and more) and code reviews are performed by Software Development team members.
• Comprehensive, continuous automated testing is carried as part of the build process (unit tests) and as a automated integration tests with an internal automation system.
• All tickets assigned to the release must be reviewed, including having suitable automated tests and those tests pass.
• A Release Meeting is held to confirm the features to be included in the release, discuss risks and review any unresolved “critical” or “blocker” level tickets (these issues are defined as those preventing accurate delivery or acquisition of data.) The meeting includes all of the Scrum Masters, Product Owners/Sponsors, some senior or lead developers, automation test engineers, interested parties and, most importantly, the approving representatives mentioned above.
• Regularly scheduled software releases occur on a monthly basis. An exception is made for “minor releases” which could occur at any time during the development cycle to address “blocker” or “critical” level issues only.
• Changes for each release are documented in Release Notes in two formats: internally, using JIRA’s fix version feature, which is affixed to the Release Meeting minutes, and a publically accessible page with plain language feature-orientated Release Notes.
• Relevant designated stakeholder representatives for each group are notified of an impending release date. If the release will cause any system outages, scheduling conflicts are checked.
• A banner message is posted on all Oceans 3.0 webpages notifying active users of an impending software update.
• The release is performed, minimizing downtime (usually ~ 5 minutes).
• Verification of success deployment is performed.
• A message indicating the finished release is sent to the stakeholder representatives.
• Each sprint holds retrospective and planning meetings and kicks off a new sprint.
• The development and QA environments’ databases are updated by replication from production, automated test suites are run and results checked with the new data.
• Test-driven, team-orientated agile development begins for the month, with daily scrum meetings, plus design, review and brainstorming break out meetings as needed. 

What documents are provided as part of the release package? 

The following documentation sets are continuously updated as an integral part of the software development process:

• Code documentation
• Internal software documentation
• External user documentation
• Release Notes (internal and external) 

How are upgrades / patches to third party software packages handled?

• Critical / security upgrades and patches are immediately applied.
• Other third party upgrades are regularly monitored. When significant improvements are made, dependency upgrades are performed on a case-by-case basis.

ONC maintains up-to-date licenses for major software systems employed by the Software Development team.