Change Management

Control for Learning Management Systems

Scope

The following change management process should be adhered to when any changes are needed to CSU Chico’s Learning Management Systems (LMS) services. This includes all the environments and services of Blackboard Learn, Collaborate, and Kaltura, and other integrated learning management applications and systems.

Internal Operational Level Agreement for supporting Blackboard Learn is located here.

System Goals

With a goal of increasing campus adoption of our LMS, we all must be committed to:

  • Keeping our systems stable and online.
  • Ensuring system software is current
  • Testing all changes before going into production.
  • Properly communicating with campus by filling all RFC’s at least one week ahead of time.

Definitions

Term Definition
Learning Management System (LMS) Blackboard Learn and its associated services.
Instance Management CSU Chico currently manages three instances of Blackboard Learn: one is the production system, while the other two are used for system testing, functional testing, and development. For more information, including a detailed component breakdown, see Instance Management.
Requests for Change (RFC)

Before changes are made to production LMS components, DLT will create an RFC at least a week ahead of time to allow for testing and discussion.

Changes to non-production systems do not normally require an RFC, except for systems such as lmsdb2 that are also hosting production standby systems.

Change Advisory Board (CAB) CAB meets weekly to review all system changes and discuss their potential impact on campus operations. Each proposed change is voted on for approval. Issues and changes to the process are discussed by the board.
Major Releases and Updates

Major releases, such as service packs or similar upgrades, to any LMS component may require a substantial effort. Therefore, a project plan should be completed before non-production implementation and testing.

LMS Advisory Group

The LMS Advisory Group includes representatives from FAAF, ITSS, CMT, DLT and TLP, who participate in a weekly meeting to discuss topics related to LMS support. Meeting minutes are kept on the DLT website.

System Schedule

Both tentative and approved plans are currently published in the Blackboard Learn Exchange account and calendar.  

Maintenance Log

All LMS system downtimes, both scheduled and unscheduled, are published on DLT’s website helping to foster application transparency and accountability.

OS, Database and Application Patching

Weekly Evaluation of Available Patches

DLT team will monitor, as well as consult with peers, about any updates that are available for Blackboard Learn and its associated services. These include building blocks, LTI integrations, Cumulative updates and new BB Learn releases, OS and Database patches.

Before going into the production system, each of these must be first evaluated against their urgency and impact to the system. Based on that evaluation, the DLT team will suggest the priority order of the maintenance schedule for review by the Blackboard Advisory Group.

Once approved by the Blackboard Advisory Group, the DLT team will update the published calendar highlighting the milestones listed in the process below. In addition, DLT will then prepare a set of system and functional testing plans that are appropriate to the changes proposed.

Normal Processes

Step Notes
Non-production install DLT will take non-production systems offline to install changes, including patches and other updates.
System testing

DLT will be primarily responsible for system testing.

The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving to production.

Functional testing

TLP will be primarily responsible for functional testing.

The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving to production.

Final GO/NO GO decision DLT and TLP will report on test completion and make a final decision regarding a move to production.
RFC created If a go-ahead decision is reached, DLT will create an RFC.
RFC approved If CAB approves the RFC, DLT will schedule any necessary downtime for production maintenance.
Changes installed

DLT will install the change, including application shutdown as needed.

Changes will typically be made in the LMS standard maintenance window, Thursdays from 5:00 AM to 8:00 AM.

Exceptions to normal processes

Exception Notes
Blackout Periods

At the start and each of each major term, we will not schedule changes during a 2-week blackout period. These periods will begin one week before the term begins, and one week before finals week.

These blackout periods will typically occur in January, May, August, and December.

Emergencies Emergency patches to resolve security issues, system instability, and similar issues may bypass some or all of this process.
Zero-Day Vulnerabilities Patches to fix zero-day security vulnerabilities will be evaluated on a case-by-case basis.