I started working with Open edX in the last months of 2021. I have been involved in new test and live environment installations, maintenance and development of existing installations for a long time. Therefore, I am responsible for the technical infrastructure of Open edX at Artistanbul. Every day we learn a new technical detail about Open edX. I can say that I was convinced a long time ago that it was not possible to fully understand this software. After taking over the Open edX processes, the most difficult task I have had so far has been to update 4 versions in test and live environment.
Preparation phases before version update
One of the most important habits I gained at Artistanbul is to prepare a to-do list for myself before starting work. It starts with the first things that come to mind and gradually evolves into a list where all the details are written in order. In operational work, no step should be skipped. I believe that the to-do list is also very important for determining company procedures.
In the preparation phase for an Open edX update, the current version information, the version path to be followed, additional changes to be made before and after each new version installation, and database migration details should be examined as a priority. The most important point in this step is the additional changes that need to be made.
For example, in an Open edX installation, while compiling Docker images used by LMS and Studio software, additional theme enhancements are also compiled. During version update processes, whether an intermediate version is compatible with your theme should not be your priority. Therefore, you may not include additional theme enhancements in the build until the last image build step. Thus, you can save time when compiling an Open edX image consisting of a long Dockerfile.
In addition, settings such as SMTP, database information, domain name and Open edX feature switches that are switched on and off as needed should be checked. A possible incompatibility in these settings may cause errors in the tests and progress in the wrong direction. As a result, my personal preference is to take backups with all the details and clearly determine the roadmap to be followed.
This preparation phase may seem to take a relatively long time. We owe the fact that we do not encounter any problems when updating a complex software like Open edX to the ‘effort’ of preparation.
Database migration during version update
The issue that made me think the most during the updates was the database differences between the 4 major versions.
As it is known, Open edX has come a long way in the transition to Micro Frontend infrastructure. In the Koa version, many code blocks offered with Django are not used in the frontend. The API is responsible for providing data to MFE applications, each of which consists of separate code repositories. Therefore, when any data structure changes, care must be taken to ensure that it is fully compatible.
Our top priority was to take backups at every step before executing database migration commands and to keep these backups until the version update is completed. Even if we do not encounter any database errors, we have to take backups to avoid data loss in disaster scenarios.
Open edX Docker images
During a version update, most of the time is spent waiting for Docker images to be compiled. Here’s the maths: There are about 12 minor releases in 4 major version updates. It is necessary to compile separate images for Open edX and MFE images. In other words, 24 image builds in total. Since the dockerfile will change almost drastically, the ‘cache’ feature is almost useless at almost no point. Therefore, it may be necessary to wait 3 hours in total to compile 24 images.
At Artistanbul, we have greatly reduced the compilation times with various methods depending on the needs of our customers, but unfortunately we can reactivate all these changes in the last step during the version update.
Final controls and delivery of work
After the 4 major version updates are completed in the test environment, it is confirmed by me that there is no data loss in the first stage. Thus, our Artistanbul and customer test processes begin. In our test approval process, all system controls are carried out in detail. Updates made in the test environment are also made in the live environment and the whole process is completed.
While delivering the work, the certificates that the users are entitled to, the course completion rates and the compatibility of the course contents are primarily checked. Thus, when the entire system is checked to be functional, we are ready to deliver the work.
All in all, I am very happy that we did not encounter any mishaps during the version update, which is the longest and most challenging work I have completed at Artistanbul.