Upgrading to Sakai 2.9

Transcript

1. University of Dayton Shhhhh – Don’t tell the Faculty. We’re Upgrading to 2.9 Presented by: Ryan Allen – rallen1@udayton.edu Assistant Director of E-Learning Systems and Support Services Jerry Timbrook – jtimbrook1@udayton.edu E-Learning Specialist University of Dayton
2. Who is this for? • Schools with small-mid sized staffs that are looking to upgrade to CLE 2.9 • Schools looking for a strategy for incorporating customs It’s Not Terribly Technical 109: BOF: The Technical Side of Sakai at a Mid-Sized University Paul Dagnall & David Bauer Wednesday: 11:00-11:45 (Gaslamp) Who is this for?
3. 3 Intended Takeaways 1. A management roadmap for moving from ~2.6 to 2.9 with a good amount of customs 2. A method for soliciting faculty feedback and load testing 3. Some reassurance that this is possible at a mid-sized university (although it sometimes felt that it wasn’t) 3 Intended Takeaways
4. University of Dayton • Private University founded in 1850 • Catholic/Marianist • 7,000 Undergrad / 4,000 Grad Students • Sakai is branded as ‘Isidore’ at UD • Sakai has been in place for 5 years • Supports appx 775 instructors in 2,000 course sections each semester • 10% fully online classes
5. Background of E-Learning Lab • E-Learning Team has five members • 3 E-Learning Specialists • 2 Web Developers • Make modifications based on faculty feedback • Possibly too often • Utilizing JIRA to document process (no surprise) • Typical Development Cycle: • Each member identifies top tickets • Vote for priority • Three week development cycles (most of the time) • Release to campus Background of E-Learning Lab
6. The 2.6 Status Quo • We felt stable in the summer of 2012 with 2.6 o We had last done a major upgrade (2.5-2.6) during the summer of 2009. o Avoided 2.7 and 2.8 but grabbed features we liked/needed from them. • Life was spent fixing bugs, managing our server environment, and adding new features. o More bug fixes or new development? • "But that's in (fixed in) 2.9" The 2.6 Status Quo
7. Forward to 2.9 • Why 2.9? • Stay current with community • Lots of fixes for open issues • Why not 2.6 -> 2.7 -> 2.8 -> 2.9? • 1 Large code merge vs. 3 code merges • Our goals: • Move to 2.9 • Little to no re-training for faculty • No one notices that it's a BIG upgrade  Break nothing in existing courses while better facilitating future course development. Forward to 2.9
8. Implementation Plan • Plan created by development team • Goal: 9 month tiered rollout plan • September ‘12 May ’13 • Just E-Learning Staff • Beta Group • Summer Term • Fall Term • Facilitation of this plan required 4 big steps Implementation Plan
9. Step 1 – See It • Get 2.9 up and running (2.9.b07) o See what it looks like o Evaluate the OOTB toolset o Make sure it's what we wanted (maybe we should consider moving to the more established 2.8 if it wasn't?) Step 1 – See It
10. Step 2 – Make Decisions • Evaluate our current 2.6 customs • Look at every Jira ticket (500+) • Decide what we wanted/needed to bring to 2.9 • Identify customs already added to 2.9 that we wouldn’t need to move (30%) • This left us with approximately 350 tickets that we had to do something with. • Merge/ Rework / Abandon Step 2 – Make Decisions
11. Step 3 – Do the Work • Re-apply each custom to 2.9 one-by-one • Strategic Decision: Get the 'big ones' handled first, come back for the rest later. Step 3 – Do the Work
12. • Each tool had a developer and a support member responsible for it (two sets of eyes) • Developer marked as “Complete” • Support marked as “Closed” Testing every circumstance imaginable became immensely important – both as the ticket was closed and as new tickets were completed. Step 4 – Test, Test, Test Step 4 – Test, Test, Test
13. The Fall Semester • Development of new features in our production 2.6 environment halted • Big culture change for UD • 90% of tickets merged • The first 90% is the easy part • These changes were pushed to a ‘staging/testing’ server for review (Beta-Test) • Planning for the spring semester • Create a server that a limited number of instructors could run their classes on (Beta) The Fall Semester
14. The 'Beta Test' Server • Our “ground zero” for testing 2.9 • A snap-shot of our 2.6 database was taken and up-converted to 2.9 to be used... • This is a process we would need to repeat two more times • Skin/Appearance wasn't a priority at this point • Created overhead (time) getting permissions configured to connect to our SIS and Course Integration servers to be able to simulate real activities. The ‘Beta Test’ Server
15. The 'Beta' Server • Once our testing and development was far enough along we created a more visible 'beta' server that would be used by faculty during the spring semester. • Branded and polished • Important for review by senior leadership to established continued support/buy-in • Separate server from production • isidore-beta.udayton.edu (more overhead) The ‘Beta’ Server
16. The Beta Users • "200 extra sets of eyes" • Who were they? • 8 instructors, 11 courses • Variety of departments, skill levels, and user profiles • Didn’t select users if key features they would need weren’t ready The Beta Users
17. The Beta Users Getting Them on Board • Meet 1-on-1 with instructors to showcase the Beta server & explain our plan • Expectation set that things might not always be ‘sunshine and roses’ • Moved course content for them (to entice) • Created a ‘shell’ site on the 2.6 server to direct students • Provided explanation for students The Beta Users
18. Seen only by E-Learning Team Beta Test Beta Seen by E-Learning Team and selected instructors/students Development Testing Code Progression
19. The Spring Semester • Complete the remaining (and important) 10% development work • Niche features (course creation, reply privately, etc…) • This ‘stuff’ better be done by May or I’m quitting. • Beta Semester Classes Running • Monitor a 'real' class load on the Beta server • Identify and fix bugs • Sometimes our testing is incomplete and unimaginative (found out from past experiences) • Collect feedback from students and faculty The Spring Semester
20. • Database conversion testing • What things were not 'converting' properly and would negatively impact existing courses? • Time intensive • Move from 2.9.b07 to 2.9.1 • Constantly revising our scope and timeline • Maintain 2.6 Production Server • We thought that we'd be able to cruise in to the upgrade with time to spare and all the tickets closed but there were plenty of other things that took time away from this project. What Else Were We Doing in the Spring?
21. Collecting Feedback Collecting Feedback: • Google feedback form in each site • Hosted two focus groups (with lunches!) for Beta faculty • Direct Feedback • TaT Prioritization Missed Opportunity • Student feedback was not directly sought (faculty forwarded student comments/issues to us) Collecting Feedback
22. Staying Focused • 9 months wasn’t as long as we thought • Picked deadlines to stay on path • How did we respond when we missed deadlines? • Differing interpretations • Self-inflicted May release • Developer/Support Team Communication • Fortunate to be co-located • Regular team updates • Managing expectation gaps • Stress was high Staying Focused
23. The Big Day • We chose the day after Spring grades were due to upgrade (6 am-noon downtime) • Less than 1 week before first day of class for summer course • Heavy ‘online only’ term • How did we communicate it? • Solicited feedback from Beta users • Campus emails and MOTD information • Quick “new features” videos • What were the results? The Big Day
24. Results • Upgrade and database conversion was quick • System back online after only 3 hours of downtime • Most users were: • Not negatively impacted • Pleased with the update • Unaware at the enormity of the upgrade •Achievement of goal, but…… • Long 2 weeks following the upgrade fixing unforeseen issues Results
25. Lessons Learned • What would we do the same? • What would we do differently? We want to stay current with the community's code moving forward. No more of this. Lessons Learned
26. Questions for You • What pieces of our framework can you borrow for implementation at your University? • What different factors do you have at your University that might require a different approach? Questions for You