Tips for collaborative development of eLearning modules
It is always difficult to coordinate efforts on large teams of programmers, especially when it comes to version control when developing several eLearning modules in a project.
Let’s suppose you have a team of five programmers and 3 of them are invested in one project, while the others are assigned to a different project or act as a backup, in case any issues arise for any of the main 3 programmers of the project.
One option is to have a shared drive internally in the office where all programmers back up all their files (and this should be in place, as a best practice) but then, versioning can be a bit of an issue.
The other option is to use a subversion server or SVN, which not only can create backups of our eLearning project, but it can create revisions of the files used in the project. This means, every time we submit the files to the server, it doesn’t overwrite what’s in there, but creates a new revision of the file, that can help when we want to unmake any changes, we just rollback to a previous revision.
Here is a diagram of how a SVN server works, in theory:
As seen in the diagram, a SVN architecture consists of a bidirectional communication between a server and a workstation(s), in which the SVN server contains the head revision of our eLearning module and the workstations contain the working files.
Let’s quickly define what head revision and working files mean:
Head revision: We can say it’s the main copy of the files. All the workstations check in and check out files from here.
Working files: Are the independent files stored in every workstation involved in the project.
The workflow of the SVN server can be briefly described like this, assuming all the services and tools are already in place:
Head revision is created. Here, the file structure is created in the server, and the main files are copied over.
Workstations connect to the SVN server and download the files.
Programmers check out the files they need to modify. A file that has been checked out by a programmer, becomes read-only for all the other members of the team.
Programmer modifies the file and saves it to the working copy folder.
Programmer checks in the file to the server. This means the file is submitted and a new revision is automatically created.
Programmers sync their files to the most current version.
Steps 3 to 6 are repeated until the project is finished.
The advantages of subversioning files, are that we have a more controlled environment for the files that are part of our eLearning project, we have revisions, which means we can rollback our files as much as to unmake changes and, anyone can connect to the SVN server and will automatically retrieve the most current version available in the head revision.
