We are working on the release of RAFT II. This is a major release. This checklist tracks is the current release path of RAFT II to the service operations, primarily from the Business Intelligence development team to Customer Support, Training, and Server & System Administration. Change Management - Enter release date, and other significant dates, on Change Communications Calendar. 
- Exchange resource name: IS&T: Change Communications
 - When these dates change, communicate to ist-pipeline list.
 - This has not been done in a while, dates have changed a lot.
 
  - Planned major milestones recorded on wiki home page.
 - Send announcement and change log to ist-pipeline@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.edu and 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.
 - Contact IS&T Communications for public release announcement. 
- If sending outside of IS&T, send draft release announcement to IS&T communications team at least 2 business days prior to release.
 
  - Inform ist-pipeline@mit.edu, pipeline of release at least 1 business day prior to release.
 
 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.  ChecklistWorking on order of priority and chronology.  Initiation - Define points of contact from IS&T Teams to Engage, right. 
- Contact help desk at inception to determine proper level engagement.
 - Contact training & docs 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
 - Contact SE Web Services 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 -decision, acceptance criteria.Code management/versioning and continuous integration plan with release engineer (SE Web Services)
- in May, community release in June. Still no hard transition plan for RAFT I users?
 
  - Review need to de-support of previous version(s), communications to current users.
 - Create communication plan, based on stakeholders identified in prior steps.
 - Create testing plan, with QA resource if available.
 
 Executing Configuration Management - Critical Path: Need stable test environment!
 - Migrating from RAFT I environments to new, clean VMs for RAFT II 
- raft-test in place, needs PHP downgrade?
 - raft-r1, new raft production, does not exist yet.
 - Await decision on budget for drupal-based online help systems. bi-help-dev installed on temporary system so documenation staff can begin work
  Provision systems, VMs, based on initial architecture plan - Update datacenter SLAs with technical, financial, business contact information.
 - Training curriculum, work with Training to ramp-up Help Desk (business-help).
 - Form ad-hoc architecture review team. Review initial architecture.
 
 Monitor and Control - If actual dates do not match previously expected dates, update calendar.
 - Twice-weekly roundup of Jira issues, open bugs related to next sprint.
 - 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 at least 1 business day prior to release.
 - Execute (Send announcement, post software for download, etc.)
 - Second architecture review, same reviewers.
 
 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
 Image Removed http://kb.mit.edufor Image Removed 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. 
 Open Questions - SLAs for help desk, operational support, etc. What is acceptance?
 - Escalation paths for help desk and ops, where to documenent?
 - Documentation consolidation: bring more in line with de facto IS&T practices? Maybe not this phase.
 - Expectations for new communications plan: better stakeholder engagement.
 
 NotesWe 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.  Release and Deployment Management - OLA: business-support team engagement, OLA in development: Service Levels Development 
- Developing blanket OLA between business-support and Business Intelligence team.
 
  - Code management/versioning and continuous integration plan with release engineer. Deploy from Bamboo or directly from SVN.
 
 Evaluation and Testing - See "evaluators" list at right. Responsible parties for internal evaluation. Must sign off. Second architecture review still required by this group.
 - Input and sign-off by Usability Team: Usability & Accessibility Reports. 
- Stakeholder committee schedule in place, core business users signed up for rolling usability-test plan.
 
  - BI Team to provide smoke-test/system health page for Customer Support? 
- business-help and business-intelligence teams to perform smoke tests for every patch or update during burn-in period (six week from go-live).
 
  
 Knowledge Management - Training Plan 
- Training mutual venture of SE Training team and COUES Training team.
 - Training curriculum, work with Training to ramp-up Help Desk (business-support).
 
  - Online Help: SE Training, Mark Wiklund. 
 - Develop RAFT escalation scripts from Tier 2 (business-support) and Tier 3 (raft-support). Support Escalations Outline
 
  |