Source Files & Version Control Best Practices

Hi, Kevan,

When there is (or there may be or will be) more than one developer, I think it's vital to have a shared site for storing source files. 

I feel lucky that I haven't had to work on the same course with multiple developers, so I haven't run into the issue of how to control access and versioning in that situation. Obviously, there needs to be a process for handing off the file when another developer will be working on it. And lots of communication to ensure that two people aren't editing different copies at the same time. 

As for keeping the history: yeah, one of my main clients needed to do that for compliance/tracking purposes. Here's how we handled it:

• The shared site (SharePoint) had one main folder per project. 
• Within a project's folder were sub-folders for each version. 
• For each version, there were more subfolders:
  • Source files: This stored the .story file, plus videos, audio files, special graphics, and/or other items that would be needed to re-create the course.
  • LMS files: This stored the published SCORM package, plus the LMS forms the company used, and the assessment key if there was a test. 
  • Supporting files: This stored other items that needed to be saved, like design docs, statement of work, and reviews.
    • Yeah, they even tracked reviews. We used a Word file with a 2-column table. The left column was for screenshots from the course (e.g., the images you'd see if you published the course to Word). It also had programming notes where needed to explain interactions. The right column was where reviewers put their comments. When a slide was updated, that row in the table was shaded in gray. That kept the original image and the comments in the file, but the gray shading made it obvious that the image was no longer current. This meant we could see who asked for what changes and how they were implemented for the entire review process.
    • At the end of a project (i.e., completion of a given version),  a copy of the review file was edited so it only contained rows for the current slides/layers. THAT could then be given to auditors or others who needed to see what was in the course but who wouldn't be expected to view a source file nor step through a published course. And that file was later used to collect comments when the course needed to be updated.

There was also a spreadsheet with basic info about each course, e.g., the most recent developer, the current version #, the course owner/SME, etc. As with any database, the trick is ensuring it gets updated when needed.  :-)

I hope this gives you some helpful ideas!