RD3: Publishing Modifications to Existing eLearning Course Projects
We have a customer based outside of the US that delivers several of our online courses through a third-party Learning Management System (LMS). They were in the process of rationalizing their fleet, and this required an extensive modification to one of their courses. When I say extensive, I mean very time consuming.
Since Avsoft courses exist solely in the cloud, this presents a problem: how do you modify a course that is actively used without disrupting the training?
RD3’s Production Server Streamlines the Process of Updating Courses that Are Already Live
RD3 solves this particular problem by using a “publishing” concept. In general, publishing is the act of making information, literature, music, software and other content available to the public. In order to do this with a cloud-based system, you need to have two copies of a project – one copy is not available to the public, and the other copy is. These copies are initially identical. Then, when you need to modify a course, you work on the non-public version while the target audience uses the public version. The problem with this process involves where to put these two copies.
One way is to keep both on the same server. However, there are issues with this particular method:
- Everything is on a single server – This is not ideal if you’re trying to provide a high reliability system.
- Aircraft online courses need a lot of room – Some of these courses can be up to 1 gigabyte or more in size. Eventually, you’re going to run out of room on the server.
- The database will increase in size – You need to keep two copies of the data, and this also increases the disk size requirements.
The other option is to use a dual server architecture, so each copy resides on a separate server. This is a more expensive solution because you now need two servers. However, the reliability increases, and the odds of both servers going down at the same time are very, very small.
The second method is the one used by RD3. The server where we do all our work is called the development server, and the other server is called the production server. When we publish a project, we clone the project in the development server, and then place the clone on the production server. In the process, we’re updating the version number of a particular course.
As an illustration, the server on the left is our development server, and the one on the right is our production server. One noteworthy point is that the transfer is only one way: development to production.
Because the servers are not physically connected, the transfer happens over the internet, and this can be time consuming depending on the number and size of files.
RD3 Production Server Simplifies the Process Compared with Using a Third-Party Commercial Development Tool
If you’re in development business, you’re probably saying to yourself – “So what? We do the same thing!”
Well, that’s true. Using an off the shelf commercial development tool, you can handle the same scenario by working on a copy of the course located on your workstation or company intranet. When you’re done, you simply update your course on the LMS. But the big difference is how this update occurs.
Let’s examine the update process using an off the shelf commercial eLearning development project. For this example, let’s assume that only one graphic in the course has changed.
The steps involved in this process include:
- Change the graphic in your file
- Export – this creates the Manifest that contains all the files in the course as well as the required xml file
- Upload the manifest to the LMS
- Update the manifest in the LMS
As part of this process, you have to move the entire course (e.g., 1 gigabyte) to simply change one graphic.
The process in RD3 is simpler:
- Change the graphic in the project
- Publish that single graphic
With RD3, you only change what needs to be changed on the production server.
Time Stamps Make It Easy to Track Changes in the Project
In order to do this, we need to precisely track what has changed in the project, and this is done with time stamps. Any change in a database record automatically updates the time stamp of that record. In addition, each file (such as audio or graphics) has two time stamps:
- A creation date
- A modified date
We use the latter as the file time stamp. We then carefully track these time stamps on both the development and production servers.
Only the Files Being Changed Are Republished
RD3 incorporates a publish function. This is a web page that shows the status of each part of a course.
RD3 compares the time stamps on the development and production servers, and highlight in red those parts that need to be published. In the example above, some of the course assets (graphics/audio) need to be published, and this is indicated by the red row as well as the publish button in the right-hand column.
During the publishing, only those files that have been changed since the last time the file was published are impacted. RD3 only moves what has changed, and the publishing takes a few seconds.