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.

MyUW serves over one million unique logins each month. In addition to constant uptime, our users have come to expect an intuitive and valuable user experience. The MyUW Service team uses a robust change management process to ensure these outcomes. The MyUW change management process migrates applications developed for MyUW through the development, integration, testing, acceptance, and deployment phases of the Systems Development Life Cycle. The process relies upon documentation and repeatability to ensure consistency in a multi-tenant system. Our campus partners actively participate in this collaborative process and play a key role in maintaining the high quality of the service. This process enables MyUW to update frequently without interruption to the service.

Migration Requests

We work collectively to minimize the risk of an outage or a regression during the migration of changes. Key aspects of the process are submission of Migration Requests, active testing and verification, and notification of approval. The process is designed to be reliable and repeatable. Shortcutting parts of the process can lead to problems that not only affect the application being migrated, but other tenants hosted within MyUW.


The MyUW Infrastructure Team maintains four tiers of server environments to support the change management process: TEST, QA, PROD STAGE, and PROD. Much of the development can be done independently in local development environments. Developers can test their applications in a shared TEST environment by committing their changes into source control. The Infrastructure Team sets up continuous deployment automation during the bootstrapping step for new applications. When the developer is satisfied with the state of an application on TEST, they can begin the process of migrating to QA.

Migrating Applications

Developers indicate code is ready for testing and verification by submitting a JIRA Migration Request and moving the ticket to ‘Approved for QA’. The MyUW Infrastructure Team will address the ticket on an as-available basis. At present, the MyUW Infrastructure Team typically stages changes to QA within one business day. To expedite this process, the developer is encouraged to submit GitLab Merge Requests for QA and PROD in their project’s overlay repository. The developer should include links to these Merge Requests within the Migration Request ticket. Developers can track their Migration Request on the Migration Board.

QA Deployment

Once deployed to QA, the developer is responsible for testing and verifying expected behavior. If the change may affect the the way the application interacts with the portal (or other tenants), the developer is encouraged request assistance from the Infrastructure team in assessing the impact of the change. When the quality of the change has been verified, the developer can move the Migration Request ticket to ‘Approved for PROD.’

Production Deployment

Migrating the code to the QA tier is a test drive of the process that will move it to production. After a Migration Request is approved, the MyUW Infrastructure Team will stage the change in the Production Staging environment. Similar to the QA migration, the developer is responsible for testing and verifying behavior in Production Staging. If no problems are found in the staging environment, the change will be included within the next scheduled production deployment.

The MyUW Service Team schedules production deployments during MyUW’s routine Tuesday morning service window between 5AM to 7AM. These deployments are performed without an interruption in the service’s availability by using a Blue-Green deployment strategy. If at any point during the deployment, the new release is found to be problematic, the deploy is aborted and the servers remain on (or are rolled back to) the last known good configuration. Migration Requests should also capture any back-out plans specific to the change being migrated. Developers should approve a Migration Request to production the week prior to the anticipated deployment date. Emergency changes on tighter timelines are possible, but should be rare and exceptional. Migrations that do not leverage the testing opportunities within the change management process increase the risk of a flawed execution.

New Applications

The MyUW Service Team prefers as much notice as possible about new applications being developed for MyUW, with initial deployment dates being specified at least three weeks in advance. The MyUW Infrastructure Team requires this time to be able to incorporate the bootstrapping work into its routine workflow. This time should also be used to prepare the Help Desk to support the new application.

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.

MyUW Change Management Timeline

For more information

Details about the MyUW change management process can be found at MyUW Deployment Workflow.


See Also:

Keywords:MyUW change management release process development migration portal sla   Doc ID:67378
Owner:Laura S.Group:My UW-Madison Portal
Created:2016-09-30 09:59 CDTUpdated:2020-06-30 10:37 CDT
Sites:My UW-Madison Portal, MyUW System Portal
Feedback:  0   0