Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column

This documentation is for planning the release of RAFT PhII to the support areas of IS&T. Other parts of the project plan and implementation details that are not relevant to support teams should go elsewhere.

Checklist

Not in Working on order of priority or chronology yetand chronology.

Initiation

  • Define points of contact from IS&T Teams to Engage, right.
  • Form release team.

Planning

Executing

  • Update datacenter SLAs with technical, financial, business contact information.

From Resources

  • Enter release date on Change Communications Calendar or email dates to release-core@mit.edu.
  • If you require a custom installer, complete SWRT's Installer Support Request Form at least two week prior to release.
  • Complete Release-Decision Template.
  • Form release team.

From Impact (including high-impact items though this project really doesn't rate)

  • Create/update portfolio listing (TBD).
  • Place release date on Change Communications Calendar or email dates to release-core@mit.edu.
  • Send announcement and change log to release-core@mit.edu once release is complete.
  • Update any known open issues affected by release and close.
  • If sending outside of IS&T, send draft release announcement to IS&T communications team at least 2 business days prior to release.
  • If actual dates do not match previously expected dates, update calendar.
  • Contact help desk at inception to determine proper level engagement.
  • Contact training at inception to determine proper level engagement.
  • Contact documentation at inception to determine proper level engagement.
  • Contact key stakeholders at inception to determine proper level engagement.
  • Review need to de-support of previous version(s).
  • Discuss release with DITR.
  • Contact production@mit.edu to schedule publication of software grid to coincide with sending of release announcement.
  • Inform release-core@mit.edu of release at least 1 business day prior to release.
  • Send software grid revision to production@mit.edu for review at least 1 business day prior to release.
  • Execute (Send announcement, post software for download, etc.)
  • Contact DLCs at inception to determine proper level engagement
  • Contact Testing & QA at inception to determine proper level engagement
  • Contact User Experience at inception to determine proper level engagement
  • Consider how to support early adopters
  • Create communication plan

From Risk

  • Search http://ist.mit.eduand http://kb.mit.edufor any articles that would be invalidated by release and update as needed. Contact istweb@mit.edu if you are not sure how to update this documentation.
  • If posting new software, contact the Software Release Team to ensure that previous and new versions are archived in their definitive software library.
  • Test software on all supported operating systems.
  • Create testing plan.

Notes

We are a pilot for IS&T's product-release checklist. We used it as a base for this plan though it was developed for distributed/desktop release. Notes for Release-Core.

Product-Release Checklist. You might not have authorizations to view the release-core wiki.

Based on this system's criteria, RAFT is Resources: Moderate, Community Impact: Moderate, and Risk to IS&T: High.

Column
width300px
Panel

IS&T Areas and Teams to Engage
Points of Contact TBDfor execution and acceptance.

Accessibility and Usability: TBD
Database Administration Team: TBD
Help Desk: TBD
Quality Assurance: TBD
Server and Systems Administration
Training and Documentation: Mark Wiklund
Web Services

Release Team
To stage and release RAFT.

Technical Lead: Amon Horne
Release Engineer: TBD
System Operator: TBD
Database Administrator: TBD

Email Lists, Stakeholders

TBD