MyUW (uPortal) Change Management Overview
MyUW serves over 166,000 users who rely on us to be continually available to support their navigation of university services. To maintain service up-time and confident service delivery, MyUW has change management practices valuing a repeatable migration process that ensures version control. Changes to MyUW are first made and tested in non-production tiers before they are moved to production.
This document is intended to help UW-Madison and UW System Partners understand the process and lead times when requesting new or changed content requests in MyUW.
Distributed developers who utilize the MyUW framework to create custom applications can skip to Migration Requests for the process to migrate apps and/or changes to apps through testing and into production.
Requests for New or Edited Content
Campus partners can request new or changed content to MyUW at any time by submitting a request through the DoIT Help Desk at help@doit.wisc.edu.
Banners, notifications, and most tiles are prebuilt templates that meet accessibility requirements, so as soon as the campus partner can provide all the necessary information (e.g. url(s), descriptions, audience, etc.), the MyUW team can quickly create the content, as soon as the team has capacity to address the request.
MyUW is an agile development team. It has an ongoing backlog of requests, operational and maintenance needs, and user improvements. The team works in two-week sprints. Priorities for each sprint are selected in advance, ensuring maintenance to keep the service available is priority 1, followed by our partner needs based on soonest production date needs as well as complexity and impact to users.
When should I submit my request?
As soon as you know you need content in MyUW, you should email the help desk so the MyUW team can hold time in future sprints for your change. Three weeks in advance is ideal notice for most requests. Emergency needs may be able to be handled sooner, depending on other priorities in progress.
My request is simple, so why can’t you do it immediately?
Regardless of the size of the request, the team always has priorities in progress. When team members finish the priorities for the sprint, they may have capacity to take on additional small tasks. If not, it will be prioritized in a future sprint.
In addition, changes, even small ones, are made in non-production tiers of the service, then moved up to a quality assurance (QA) environment before production to maintain version control and ensure 24/7 availability. Once a campus partner’s request is ready in QA, they will receive a link to view the content for final changes or approval before it’s moved to production. To maximize development time, MyUW bundles and moves as many changes as it can together into production, creating more time for the developers to execute more requests and needs.
Review the following sections for more information on how MyUW moves changes through tiers to production:
Migration Requests
Developers may not move changes to MyUW hosted applications directly into production. To move changes to production, you must submit a migration request through the MyUW team to minimize the risk of an outage or a regression.
Submit a Migration Request
Please send the following information to the DoIT Help Desk at help@doit.wisc.edu. Make sure to include the subject below so the request is promptly escalated to the MyUW team.
Subject: Migration Request - Escalate to MyUW Team
Body:
Click below to select the text, then copy and paste into your email.
-
-
Update [app name] to [version number]
-
[briefly explain the change(s)]
-
QA Date: [ccyy-mm-dd or ‘at your convenience’]
-
Production Date: [ccyy-mm-dd or next available]
-
QA Merge Request: [insert link]
-
Production Merge Request: [insert link]
-
Include details on any ‘back out’ plans to this change
-
Tiers
The MyUW 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 MyUW 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 Changes
Developers indicate code is ready for testing and verification by sending an email with all required details (see template above). The MyUW Team will send a confirmation response and move the information into our Gitlab backlog. The team will address the request on an as-available basis. Changes can typically be staged to QA within two business days. 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 email. Developers can track their Migration Request on the MyUW Migration Board. (Contact the service team at MyUW@office365.wisc.edu if you need view access to this board.)
QA Deployment
Once deployed to QA, the requesting developer is responsible for testing and verifying expected behavior. If the change may affect the way the application interacts with the portal (or other tenants), the developer is encouraged to request assistance from the MyUW technical lead in assessing the impact of the change. When the quality of the change has been verified, the developer can move the Migration Request over to ‘Approved for PROD’ in the Gitlab migration board, or change the scoped label from “In QA” 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 Team will stage the change in the Production Staging environment. Similar to the QA migration, the requesting 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 a 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 problems.
New Applications
The MyUW Service Team prefers as much notice as possible about new applications being developed for MyUW (uPortal), with initial deployment dates being specified at least three weeks in advance. The MyUW Team requires this time to be able to incorporate the bootstrapping work into its routine workflow. This time should be used to prepare the Help Desk to support the new application. The requesting team is responsible for following the service initiation process found in DoIT’s Common Service Management Framework.
The MyUW Service Team continues to work on improvements to the change management process and the service overall. We welcome feedback and suggestions for improvement to make it easier for you to develop, deploy, and manage apps in MyUW, which can be submitted from the feedback component in your MyUW experience.
For more information
If you have questions or need more detailed information about MyUW change management, send an email to MyUW@office365.wisc.edu.