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

Working on order of priority and 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.

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

  • • Contact help desk at inception to determine proper level engagement.
    • Contact training at inception to determine proper level engagement.
    • Contact Testing & QA
  • 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
    • User Experience at inception to determine proper level engagement
    .
    • Contact documentation at inception to determine proper level engagement.
    • Contact key stakeholders, DLCs at inception to determine proper level engagement.
  • Form release team, reserve resources.

  Planning

  • Enter release date, and other significant dates, on Change Communications Calendar.
  • Consider how to support early adopters or pilot users, phase out current version?
  • Define release-decision, acceptance criteria.
  • Code management/versioning and continuous integration plan with release engineer (SE Web Services)
  • 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.
  • , communications to current users.
  • Create communication plan, based on stakeholders identified in prior steps.
  • Create testing plan, with QA resource if available.

  Executing

  • Provision systems, VMs, based on initial architecture plan.
  • Update datacenter SLAs with technical, financial, business contact information.

  Monitor and Control

  • If actual dates do not match previously expected dates, update calendar.
  • Continue to ad-hoc test software on all supported operating systems, whether or not there are formal QA resources (runtime, browser).
  • If sending outside of IS&T, send draft release announcement to IS&T communications team at least 2 business days prior to release.
  • Inform release-core@mit.edu, pipeline of 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

  Closing

  • Send announcement and change log to release-core@mit.edu, stakeholder list once release is complete.
  • Update any known open issues (Jira, Request Tracker) affected by release and close.
  • 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.