Upgrading Experience, from 2.9 to 10
Here we are again !! After sharing our experience upgrading from 2.7 to 2.9 now we are ready to share our experience upgrading to the brand new Sakai 10 at the University of Murcia - SPAIN (Universidad de Murcia http://www.um.es - https://aulavirtual.um.es). In the first experience we shared a lot of info about the local customizations we have, and made them available to others when they are useful enought. We are sure that there are customizations ready to be shared and also new ones that might come.
We also want to share our route map so that others facing the same needs for upgrade can use them, reduce their time and learn from it. This is the power of the community!! At the same time, we would love to hear from you suggestions about tasks that might also be included in our upgrading process, or your advice for facing those tasks and making them easier for us.
This page will be made by the technical staff and it is mainly focused on their concerns around the upgrading process. We also intend to mention all the other staff related to this process and the tasks concerned to them.
After Sakai released its 10 version, we set a clear goal for our TEAM, move our deployed version (2.9.3) to the latest one. However, the first step is to write a simple plan, unfortunately for us and everyone in the Sakai community, Sakai upgrades do not arrives by clicking a 'magic button'. The main task concerns technical aspects, we have developed a lot of custom tools and have also changed some pieces of the original Sakai code. But, there are other tasks involved, so we are going to mention all of them at this master plan.
Evaluating Sakai 10
What do we really know about the new version? This is our first goal. When we started to migrate from 2.7 to 2.9 we didn't know too much about the 2.9 version, but know the situation is pretty different. The migration from 2.7 to 2.9 let us get much more involved in the community and do a lot of work into trunk that now is part of Sakai 10. So we know what's new in Sakai 10 because we developed some of the new features (of course not all). Also we were collaborating in different test fests during the Sakai 10 quality assurance process, and this let us know more about Sakai 10.
Look & Feel
Sakai 10 is not a challenge in terms of look&feel is pretty similar to 2.9, but we need to add some changes to get our users feel that something has change. Probably the main change of the look&feel will be on the gateway page, but not in the internal skin, we have to wait for Sakai 11 and the Morpheus project to see a new responsive design for Sakai.
There are a lot of new features in Sakai 10, some of them really interesting and also necessary. If you are interested in wht's new on Sakai 10, please look at the release notes.
Major Code Changes
Sakai 10 comes with some important upgrades, such as Hibernate 3.6.10.Final and Spring 3.2.3.RELEASE. Because of these libraries are deployed in shared folder, we also need to upgrade our tools in order to use these new versions. In the other hand another significant change is that the Sakai 10 release process only api artifacts were deployed into public sonatype repository.
Developing Process. (Jul-Sep, 2014)
The development start July 1th, 2014. I don't know how much time it's going to take us release our customized version, but it's time to see if all the work done with the previous migration has a significative impact in this process.
Testing Process. (Jul-Sep, 2014)
During test process we found some issues and we decided to use a label in JIRA to keep track of them. "UMUtoSAK10" is the label and you could check the list of jiras at the right side of this page.
I'm going to do some load testing before September and then a more specific tests.
Information Process. (Sep, 2014)
At the begining of the previous migration we wanted to make a promotional process about the steps of migration thinking in marketing perspective, but later on we realized that users don't care about migration, they only care about it works or lose data. So, for this migration we won't do anything but notifying users briefly about new features and when the change will be made, and spend time in quality assurance rather than in marketing things.
The Change. (Sep, 2014)
The best date for us to change from one version to another is right now, before the new term start in September. Actually Jul, 31th is the best date to make the migration, but that date seems to be impossible. Let's see what happend !!
Finally the migration will be Oct, 25th, is far for our initial point first because of the release dates of Sakai 10, but also due to the amount of bugs that we had to solve. We are going to be out with Sakai 10.1 (with a lot of patches added), and we are planning a minor upgrade to 10.3 at the beginning of 2015.
Since we migrated to Sakai 2.9 we got closer to the Sakai community and its SW development cycle, but it is hard to know every change happening and any of them, even a one line change, could affect your migration process. The best part of this process is that now, almost everything that does not work for us, is also a problem for many in the community and sonner or later it will be solved in Sakai, but, the bad thing is that there is an evident lack of QA in Sakai at this moment. We found some bugs that are pretty obvious, and those type of issues made us think that nothing was really well tested after the feature was introduced into trunk.
You can check all jiras opened by us during this process (more than 80), and this will continue during next weeks because with Sakai 10 in production we will discover more problems. As mentioned above, we have used a label in JIRA called 'UMUtoSAK10' to keep track of all our issues and we believe that it could a 'best practice' to share with the community since it could help someone that is upgrading to 10 at the same time or later than us. JIRA allows a user to filter by label and in an easy way you can see all issues related to someone's migration. We paid special attention to all JIRAs and messages comming from anyone from UCT (University of Cape Town) because they had upgraded a couple of months before us and therefore, they were usually describing issues or findings that could affect our new Sakai 10 instance.
One important decision made is that we have had to go into production with the classic Roster tool (Roster1) because Roster 2 still have problems for us after 3 versions of Sakai 10 (10.0, 10.1, 10.2), this is a good summary of the migration process, and a fantastic evidence of the lack of QA. We are still trying to provide patches for Roster 2 so that we can try to move to it as soon as possible.
After a few days running the new version of Sakai there are not so much issues around, we think that the change was pretty successful but there was a none reported issue with Sakai 10.1 that caused us a lot of troubles during our first hours with the new version. We've been working hard to adapt Sakai 10.1 to our needs so when 10.2 was released we had just taken a quick look to the issues added to 10.2 (and most of them were added to our 10.1 version too) but missed the most important one, mainly because it was fixed but not reported anywhere. We are talking about this jira, the issue fixed in that JIRA killed our production server twice in two days.
Did you see something strange? This JIRA is resolved, and it has two fixed versions in the same mayor release: 10.1 and 10.2, how could that happen? The thing is that this JIRA was solved for 10.1 version, but it has a bug that was fixed for 10.2, but this new bug wasn't reported anywhere else. The only clue that you have is the 10.2 in the fix version and of course the subversion tab that shows a commit into 10.x at the beginning of October (after 10.1 was released). For us, this fix was critical, our production server went down so we expected that a fix so critical was clearly mentioned in the release notes but in this case it wasn't even in this filter with "Blocker" issues fixed. A lesson to learn for the whole Sakai Community.
We whould like to specially thanks the folks attending the Sakai Core Team calls for the support they continiously gave us allowing us to contribute many fixes and letting us move forward in this community. Let's keep on improving Sakai!