COVID-19
View the latest updates and emergency notifications on the COVID-19 News & Information website.
Distributed Learning Technologies

Change Management

    Definitions

    Change Management
    A process for limiting the impact of system changes.
    Learning Management System (LMS)
    Blackboard Learn and its associated services.
    Instance Management
    DLT currently manages three LMS instances: one is the production system, while the other two are used for system testing, functional testing, and development.
    Requests for Change (RFC)
    Before changes are made to production LMS components, DLT will create an RFC at least one week in advance, to allow for testing and discussion. Changes to non-production systems do not normally require an RFC, except for systems which are also hosting production standby systems.
    Change Advisory Board (CAB)
    CAB meets weekly to review RFCs and discuss their potential impact on campus operations. Each proposed change is discussed for approval. Issues and changes to the process are discussed by CAB.
    Major Releases and Updates
    Major releases or updates to any LMS component, such as service packs or similar upgrades, may require a substantial effort. Therefore, a project plan should be completed before non-production implementation and testing.

    Advisory Groups

    Depending on which learning technologies are impacted by change, DLT consults with several advisory groups:

    Process 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.

    DLT will strive to adhere to this process when any changes are needed for CSU Chico's learning technologies, including all environments and services related to Blackboard Learn, SumTotal, Kaltura, Zoom, and LinkedIn Learning, along with other integrated LMS applications and systems.

    Maintenance Schedule

    Third-party vendors sometimes schedule maintenance windows outside of this process; when that happens, we will do our best to communicate with impacted users before the maintenance occurs.

    When DLT is able to control maintenance scheduling, we will strive to ensure maximum stability and availability for all students, faculty, and staff.

    The following maintenance windows are typically used for the LMS, and may be leveraged for other systems as well:

    • Overnight maintenance window (no downtime)
      Thursdays, 12AM to 2AM PST
      Weekly/Monthly

    • Morning maintenance window (no downtime)
      Thursdays, 8AM to 10AM PST
      Weekly/Monthly

    • Extended maintenance window (extended downtime)
      Thursdays, 12AM to 8AM PST
      Quarterly/Between Terms

    From time to time, DLT will need to schedule maintenance outside of this standard schedule; when that happens, we will be sure to communicate with users.

    In addition to the above, our schedule also considers several "blackout windows", where DLT will avoid making system changes in order to maximize stability during critical usage periods:

    • Two-week window at start of Spring/Fall term, starting one week before first day of classes
    • Two-week window at end of Spring/Fall term, starting one week before final exams

    Maintenance Logs

    All service interruptions, including planned or unplanned downtime or other incidents, are logged on DLT's website in order to foster transparency and accountability:

    Normal Processes

    Non-production install
    DLT will take non-production systems offline to install changes, including patches or 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. Refer to the managed hosting maintenance schedule for scheduling information.

    Exceptions to normal processes

    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.