MyUW Change Management Overview
This document summarizes the change management process used to migrate apps developed for MyUW from development through testing and into production. It includes important information on the timeline and communication steps.
Each month over 100,000 people log into MyUW over one million times. It is imperative that the service remains supportable and reliable. This is made possible in part by the robust and controlled process the MyUW Service Team uses to encourage a successful launch of new or modified content. Our campus partners are active participants in this collaborative process and play a key role in maintaining the high quality of the service.
Key aspects of the process are timely submission of migration requests, active testing and verification, and notification of approval. Our process is designed to be reliable and repeatable. Collectively we work to ensure that migration of changes is an unhurried progress and that the likelihood of a code or configuration mistake is minimized as much as possible. Rushing changes into production while expediting or shortcutting the process can lead to mistakes.
The MyUW Service Team prefers as much notice as possible about new applications being developed for MyUW, preferably at least three weeks in advance. The MyUW Infrastructure team needs this time to be able to incorporate the additional setup and bootstrapping work into its routine Scrum workflow. The Help Desk needs this time to ensure support is in place.
Development and initial testing
Much of the development can be done independently in local development environments (e.g., desktops). When developers are ready for additional testing and verification, they can move their code into the test environment at their discretion. Bootstrapping a new application to the test tier and implementation of continuous deployment requires cross-functional efforts most comfortably undertaken with lead time and without hurry.
QA staging, testing, verification
Moving code to QA indicates it is ready for testing and verification. It is a test drive of the process that will move it to production. Developers submit a JIRA migration request and sometimes supporting GitLab merge requests; developers can also email the MyUW infrastructure team drawing attention to the submitted request. The migration board tracks the progress. The infrastructure team typically stages the change in QA on Mondays or Fridays (see MyUW SLA) but may service requests between these windows on an as-available basis. Once deployed to QA, the developer is responsible for testing/verification and indicating if and when the change has been approved for production by updating the migration request (which will be reflected on the migration board).
Typically, developers should communicate a requested production change at least a week in advance of when that change should be in production, and the change to be promoted should be already in place in QA a week in advance of that desired production date.
Sometimes the developer knows a desired QA and production timeline when writing the migration request (e.g., when the change is part of a bigger picture of coordinated change). Migration requests support capturing these desired dates.
Sometimes the timeline for a change is flexible, depending upon how things go or the availability of approvers. Migration requests also support capturing approvals and and approval criteria or test plans.
Implementing change in QA a week before it goes to production allows time for unhurried testing and migration and allows involving more stakeholders without driving real time interruptions of stakeholders. This also typically allows staging some kinds of change in the production staging tier with time to verify the change as staged.
Typically change releases to production during MyUW’s routine Tuesday morning 5AM to 7AM service window, without an interruption in MyUW service availability. Releases are planned and release process is automated such that if a production release is problematic, MyUW can typically fall back to the status quo version from before the problematic release. Migration requests can also capture change back-out plans specific to the change being migrated.
Emergency changes on tighter timelines are often possible, but should be rare and exceptional. Change faster than the defined process increases risk of flawed execution through hurry and reduces opportunity for flow through flexibility.
Both the MyUW Service Team and Infrastructure Team continue to work on improvements to the change management process and the service overall. We welcome feedback on how improvements that make it easier for you to develop, deploy, and manage apps in MyUW.
For more information
Details about the MyUW change management process can be found at MyUW Deployment Workflow.