The University of Toledo
Cyxtera Enterprise Bare Metal offers security, control, and performance of dedicated colocation infrastructure in an on-demand model, ideal for extending colo environments or rapid market expansion. Nutanix hyperconverged infrastructure servers and leading enterprise vendor options available for workload needs. Private or hybrid cloud platforms enable cloud-first strategies, pass security audits, and create extensible hybrid environments with Cyxtera Enterprise Bare Metal. XaaS providers leverage regional and global availability zones for scalability and market expansion.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Hosted by: The University of Toledo October 21, 2019 The Fawcett Center Columbus, Ohio
Its Dangerous to Go Alone, Take This: Applying Monthly Banner Module Upgrades Sofia Olaya and Eboney Kimbrough
About the Presenters Sofia Olaya Application Support Analyst II olayasa@miamioh.edu Eboney Kimbrough Application Support Analyst II kimbroe@miamioh.edu
Challenges with Banner 8 Upgrade Process Required expensive development resources Multiple Development Teams Database Administrators Tedious and involved process Developers spent a lot time researching changes Took several days to complete upgrades Often ran into dependency and bug issues Lagged behind current versions Performed only twice per year
Challenges with Banner 8 Upgrade Process The process of scheduling Difficult to coordinate with client offices due to ongoing business activities Lack of lead time for testing Lack of client engagement Clients were unaware of patch availability and pertinent information related to them
On comes Banner 9 Upgrading to Banner 9 was an enormous project IT was temporarily restructured to focus on the migration Multiple teams across IT were involved for over a year Dedicated Tier 3 support team expanded around this time A director was appointed to manage the meta-project IT sent liaisons to client offices to coordinate upgrading each Banner module into Banner 9
Outcomes of Banner 9 Improved relationships with the client offices Built trust More communication between IT and client offices Everyone was thinking about Banner in a way that they hadn t previously Offices were primed for testing Created up-to-date test plans Regular testing windows Further upgrades could now be deployed using Ellucian Solution Manager (ESM)
Aftermath: The Idea Why don t we do this on a regular basis? Smaller upgrades are less risky Security team will be happier if we re up to date Testing is easier when it s done regularly Move the upgrade process away from expensive resources and make it more operational
The Plan - Initial Scope In Scope Banner 9 Admin upgrades and patches Banner 8 upgrades and patches required to keep Banner 9 Admin up to date Database changes required to keep Banner 9 Admin up-to- date Out of Scope Self Service Modules Banner Document Management Ethos, Banner Workflow, etc. Infrastructure changes, e.g. operating system patching, hardware, etc.
The Plan - Upgrades IT staff will install all major (e.g. 9.2.3 or 9.3) patches in DEVL and TEST on a consistent monthly schedule IT staff will initiate Change tickets and email stakeholders (Banner Leadership Team) a list of what s been installed Client offices will have approximately three weeks to test changes If client offices have not reported a bug prior to the freeze date, the patch is installed in PROD on a pre-negotiated schedule If client offices uncover an impact in testing, IT and the client office will work in partnership to fix the issue and/or delay the patching of PROD as appropriate; IT will take the lead with technical issues, and the client office will take the lead with functional issues
The Plan - Patches IT staff will install all minor (e.g. 9.3.2.7) patches in DEVL and TEST on a consistent weekly schedule IT staff will initiate Change tickets and email stakeholders (Banner Leadership Team) a list of what s been installed Client offices will have approximately four days to test changes If client offices have not reported a bug prior to the freeze date, the patch is installed in PROD on a pre-negotiated schedule Same as the monthly upgrade; IT leads technical issues, client offices lead functional issues
Implementing the Plan We built this plan hand-in-hand with the client offices, making sure that the SME from each office approved We sent out a shared Google spreadsheet requesting two years worth of blackout dates from the offices, including the reason for the blackout Then we lined-up everyone s blackout dates to reveal the weekends when we could make changes We compiled and published a schedule with the upgrade date, testing period, and test install date
Implementing the Plan We shared the plan and calendar with all of the clients at the monthly Banner Leadership Team meeting for feedback and approval We stressed that the process is not going to be perfect the first time and invited feedback and changes to improve things
What worked? Moving away from mods and using baseline functionality instead Client office testing Communication Service request form for out-of-band upgrades Overall upgrade went well
What didnt work? Many upgrades, most notably version changes, have bugs that require patches when they are released Installing patches weekly Communication Decision process for go/no-go was unclear We didn t remember to communicate in the Banner Slack channel We didn t coordinate the production changes with the Database Administrators (DBAs)
What changed? Better coordination with other teams (DBAs) Wait a minimum of 30 days before installing upgrades/patches Patches are on the same monthly schedule as upgrades Our practice of documenting solutions
What changed? How we communicate Setting up a Banner Slack channel has played a key role in this process Everyone is in one place We are able to get the word out quickly should any problems arise Better collaboration and communication with client offices We are able to quickly respond to issues reported Created overall trust between IT and client offices
The Process The Application Operations (App Ops) team reviews all available modules and patches that are at least 30 days old Evaluates all dependencies and requirements Verify approval from client offices to install upgrades Communicate via the Banner Slack channel that we are preparing for the monthly upgrade Share spreadsheet and ask for any comments or objections to be added within two days
The Process Change ticket is created for the monthly upgrade The Dev and Test environments are upgraded simultaneously with all modules currently installed in Production App Ops notifies the Banner Leadership Team that upgrades are installed in Dev and Test and provides all upgrade release notes
The Process Offices are given 3 weeks to test and report bugs or concerns If a bug is reported, App Ops will open a ticket with Ellucian Deployment delays must be approved by the Vice President of the requesting client office The Banner Leadership Team receives a reminder email a week before the end of the testing window The Solution Delivery Managers group approves Production deployment task(s)
The Process Upgrades are installed Sunday morning between 12 midnight and 10 a.m. Communicate in Banner Slack channel when upgrades begin and end App Ops documents any problems in knowledge base along with solutions that occur during the upgrade Banner forms are validated using automated testing The process starts again the following week Client offices can submit requests via a service request form for out-of- band upgrades
Challenges Self-service modules have hard-coded version numbers that need to be modified with every upgrade We have scripts in place to update various properties Mods Ensuring the client offices are indeed testing WebLogic learning curve Undocumented Ellucian bugs because we re on the bleeding edge
Whats next? Quarterly Banner Document Management (BDM) upgrades Banner adjacent upgrades Evisions Eprocurement Einvoice Ethos Banner Workflow Adopting Self-Service Modules
Contributors Tim Ward Application Support Analyst II wardtd@miamioh.edu Jeff Toaddy IT Services Management Coordinator toaddyjm@miamioh.edu
