| Section |
|---|
| Wiki Markup |
|---|
{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 order of priority or chronology yet.
From Resources
...
h1. Checklist
Not in order of priority or chronology yet.
*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) |
|
...
* 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 |
|
...
...
_Risk_*
* Search http://ist.mit.eduand |
|
...
...
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. |
|
...
...
Notes
...
h1. 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. [MITBIZINT:Notes for Release-Core]. |
|
...
[ISTPROCESS: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}
{column|width=300px}
TEST
{column}
|
|