Case Studies: Early Sakai 11 Implementation at Three Institutions
MCI's roadmap to an early Sakai 11 update
At MCI (MCI Management Center Innsbruck) we are proud to be among the very first institutions having upgraded to Sakai 11 - including a new Morpheus compatible skin for a responsive UI and MCI-specific adaptations and processes. Our user feedback has been great so far! We really would like to thank the Apereo Foundation, the Sakai community, and the developers who did a terrific job and made this possible!
For this update, the available time frame at MCI was smaller than usual – less than 5 months, of course with maintaining the 10.6 instance alongside. Changes in development and the community processes of Sakai 11 made it possible to keep a tighter schedule than ever before! We do believe that the change to GIT source code management was one of the most important factors making more timely local releases including adaptations possible.
Up to Sakai 10 we used a local subversion repository with a vendor-branch approach for keeping our source code in sync with the official Sakai versions. Importing the new community source code was an error-prone and tedious process and as a consequence was done only few times a year. Important security patches were integrated manually, bigger updates are only implemented twice a year. The time cost of the workflow enforced a sequential workflow that meant that we always had to wait for a Sakai release to have gold release status before we started work on source code integration and adaptation.
With GIT we were able to start adaptation, testing and integration *in parallel* to community development. In order to be up-to-date, we regularly rebased our changes on the 11.x-code instead of the tags. Implementing it this way, we already finalized our local adaptations when Sakai 11 was released officially.
- First local tests of Morpheus
- Last update Sakai 10 (10.6)
- Download 11.x, still without local GIT workflow
- Change of development environment to Tomcat 8 and Java 8
- First local instance of Sakai 11.x
- Risk assessment for planned update in summer
- Introduction of GIT repositories for development at MCI
- Concept for removal of previous adaptations (especially for navigation, UI)
- Final strategic decision for summer update to Sakai 11
- Local Git-Rebase workflow and documentation created, based on remote 11.x upstream and local multi-developer git repository
- Morpheus skin adaptations (mixture of scss-config and injection of a custom.css which contains our skin code not configurable with the existing scss-variables)
July 22, 2016
- Integration of latest blocker bugfixes and last git-rebase to 11.x before update.
July 23, 2016
- Official Apereo Sakai 11 release
July 25, 2016
- Update of sakai.mci4me.at to Sakai 11 (we didn't really plan to be that close to the official release date, we decided to use 25/7 about 1 month before :-) )
The update started at 13:00 CEST and was finished at about 15:00 CEST.
Administrative tasks during the update process were:
- Backup (filesystem snapshot, fast)
- Update of required environment (Java, ..., fast)
- Uploading new configuration files (sakai.properties and init scripts, debugging necessary, took most of the time)
- Deployment of new Sakai build (fast)
- Configuring and resetting user workspaces with a webservice-script (debugging necessary, took some time)
- Repairing the Favorite Sites of every user with the conversion script: java -cp "lib/*" -Dtomcat.dir="$PWD" org.sakaiproject.user.util.ConvertUserFavoriteSitesSakai11 (easy and fast)
The contrib-tools we are using are the following:
- Dashboard (using that one since summer 2013): Still not a core tool, but it just works fine for our needs, is placed on every users starting page and is everybodys favorite timesaver. Lots of trouble, but lots of benefit.
- YAFT: Still in triage (so no real user feedback), but it seems to work with Sakai 11.
- CLOG: Introduced that with Sakai 11, so no conversion experience.
- Contentreview/TII: We highly customized this one in Sakai 10, and simply kept that for 11, since the switch to the LTI-tool is coming soon (we guess).
Thank you once again & best wishes from the Alps!
IT-Services team @ MCI
If there is further interest in particular aspects of our update-roadmap, feel free to send a request to our developers:
In cases of organizational questions, you can also contact our IT-Lead:
Migrating to Sakai 11 at HEC Montréal
HEC Montréal went live with Sakai 11 on August 10th. Our migration from a Sakai 2.9/10 hybrid went smoothly. We took the decision in April to forge ahead with our migration process without knowing the release date of Sakai 11. We were confident that the community would put tremendous effort to get the release out before the fall semester and we were not disappointed!
It was very important for HEC to migrate to Sakai 11 this summer since we plan to use 2017 summer to release a new course outline tool to our users. This new Sakai tool called ‘TenJin’ is currently under development at HEC and we plan to make it available to the Apereo Community as an open source project.
-- Philippe Rancourt
Sakai 11 – Early Adopter: Notes from the Trenches at Marist College
We didn’t think we would go first. In fact, we were hoping to be somewhere in the middle of the pack, a bit out towards the front. It had been several years since Marist College had a major Sakai upgrade and it was critical we move as quickly as possible off of Sakai 2.9.4 to a new version. Pressure had been mounting since student and faculty feedback indicated the system seems “dated” and “clunky” and of course, it didn’t work on mobile devices. Sakai 11 included “must have” features like “Lessons”, GradebookNG, and a pleasant, user-centric, responsive design. To assure success, we partnered with Longsight, who worked with us in preparation for the upgrade and who was instrumental on the day of our upgrade.
With our deadline looming, we charged on. As a result we learned from our successes as well as our failures. Here’s are some of the lessons we learned.
Prepare, if you can.
In 2015, we knew we would be upgrading at some point and changed our old 2.9.4 skin to be reflective of Sakai 11 in an effort to prepare faculty and students for the change to the User Interface (UI). We made a copy of our production database and ran the Sakai 10 and 11 upgrade scripts against it. This gave us a chance to see, in advance, if we would have any data issues as part of the upgrade. We actually ran into an issue with the Job Scheduler tables; this issue was fixed as a Community Jira, saving others from running into the same problem.
Lesson learned: Give yourself a bit more time than you think you need to get your existing skin(s) into Morpheus. It does take some trial and error to get buttons and some other features set the way you want. You will also need to go through all the tools to make sure that they are themed the way you want. We ended up with a few buttons that had the text color the same as the button color. This was not the best user experience. The more skins you have, the more time you will need to dedicate to the Morpheus conversion especially if your skins are heavily customized.
Be aware of deprecated tools.
We started a bit late out of the gate in locating a solution for our faculty to migrate their Melete content into the Lessons tool. However, once a process was in place, we took initiative to reach out to our faculty, especially to those who teach fully online courses and were the heaviest users of these tools. Communication took the form of announcements, email, newsletters, and workshops. We also created pages dedicated to the upgrade on our website. We directed all customers there for the latest information related to the upgrade.
Timing is everything.
An important question arose: do we allow faculty to begin creating their fall courses prior to the upgrade? This meant jumping through some hoops to make sure that tools available to faculty building courses in 2.9.4 would be supported in Sakai 11. We switched from Gradebook 2 to Gradebook 1 as it was supported in both versions. After the upgrade we ran a script against the database to convert all the courses with Gradebook 1 to GradebookNG. This was only possible because the database tables were the same between the two tools. This method eased the impact on faculty and students for courses running during the upgrade.
- Create an inventory of tools with in both course and project sites. Identify outliers (tools that may be deprecated such as Clog or LTI tools). These are the issues we received the most critical calls about. We even had to bring back up a copy of Sakai 2.9.4 so that one instructor could grade the Clog content in his summer course.
- It may sound redundant, but prepare the faculty for what is about to change within each of the tools they use in various formats, such as documentation, outreach, and supplemental information. The jump from 2.9.4 to Sakai 11 turned out to be overwhelming for some faculty because of the changes in interface, tool behavior, and new tools coupled with impacts on course and content development and delivery.
- Don’t forget about the Adjunct Faculty. Many who teach once or twice a year may be completely unaware of the upgrade.
- Keep the Help Desk in the loop and make sure they have “how to clear your browser cache” documents handy, along with the extensive documentation regarding new features.
- Join the Sakai QA community and maintain continuous engagement. Participation offers the best opportunity to experience the latest version and prepare for new tool behavior and functional changes.
- Last but not least, keep up with the latest software. In other words, upgrade regularly.
Although we had issues and missteps, the overall the feedback we have received has been quite positive and many of our initial concerns were able to be quickly addressed. We were not planning on being an early adopter, yet with the lessons we have learned from this successful upgrade, the idea may not be unusual in the future.
-- Dede Hourican