Forum Discussion

KevanStranges-f's avatar
KevanStranges-f
Community Member
3 years ago

Source Files & Version Control Best Practices

Hey Guys,

I'm wondering if anyone would be willing to share any best practices they may have found in terms of the storage of source file(s) along with released versioning controls when it comes to developing and publishing of Learning Program/Modules.

For example; in our organization there can be several authors developing content at the same time (which obviously will over the years too).  Are best practices to use a shared-drive to share final .story (raw source files) along with any attachments and related files that may accompany that project?  

Also, what does everyone use for versioning control of published items?  This can be extremely important when relating to compliance items.  At times, we may get a request from legal to provide them with all released versions of a module over the last X years.   I've considered outputting a word-document each time we publish a version to a shared location for tracking purposes -- but word documents are very limited in nature especially as courses evolve in terms of interactivity and attached media.   I have some other ideas too but I'm curious if anyone has any best practices they can share here?

Has anyone created tracking systems of their own (e.g. in Excel) or utilize other software platforms to help streamline this process?

Thanks in advance!

  • Our naming convention for published courses uses TrainingTopic_SL_date.zip or TrainingTopic_Rise_date.zip makes it easier to locate courses when we have so many.

     

  • 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!

    • TerryGayle's avatar
      TerryGayle
      Community Member

      Hi Judy- these are some great tips! thank you for sharing. My organization is currently in the process of building a similar system (SharePoint site for stored resources and an accompanying excel to track more details of these resources). since you're future down the line with implementing this then we are- I'm curious if you encountered any knee scrapes? I'm wondering how we can best set up our team for success with this new process. 

      • JudyNollet's avatar
        JudyNollet
        Super Hero

        The basic set up works well. The trick is to get everyone to follow the process.  ;-)

        Since you're building your system now, you might want to get input from the team re: the naming conventions and such. That might get you some buy-in. And perhaps plan for some check-ins down the road that verify that all appropriate files are stored correctly. 

  • Thanks for sharing what worked for you, Lisa; this is a great tip!

    Have a wonderful day ahead! 🙂