Code Library Updates

Mike Wolfe -

Recently, I wrote about building and maintaining a code library.

In response to that article, Anders Ebro (TheSmileyCoder, Access MVP) wrote in with the following question (shared with permission):

When you have your standard modules, such as the mentioned StringFunctions, how do you deploy an updated version of that to other applications? And how do you keep track of whether another app needs the updated version.

I imagine your initial process goes something like this:

Application A
- Find and fix an issue in StringFunctions
- Export to repository folder \Application_A\Source_Code\StringFunctions.txt

Do you then manually copy it from \Application A into a general library? And how do you check if other applications are in need of the updated versions?

The problem I haven't found a good solution for is to
* Export/synch application specific modules into \Application A
* Export/synch library specific modules into \CodeLibrary

Here's my response:

The workflow you laid out is pretty close to how I do it.  Here's my process:

  • Find a bug in StringFunctions while working in Application A
  • Remove the StringFunctions module from Application A
  • Import the StringFunctions module from my Code Library folder (to ensure I'm using the latest version)
  • Fix the bug in StringFunctions from within Application A
  • Update the date last updated in a comment at the top of the StringFunctions module
  • Export the updated StringFunctions module into my Code Library
  • Commit the changes in the Code Library to version control

The primary way that I tell if an application requires an update to a code library module is to compare the "date last updated" from the top of the module to the "date last updated" for that module within my code library.  In practice, though, I generally only import an updated copy of a code library module if there's some feature in the updated version that I need in my current application.

I tend not to get too hung up on updating the module in every application whenever I make a change to it.  I use vbWatchdog integrated with FogBugz for automated error reporting.  If it's a bug that affects multiple applications, then A) I usually catch it pretty quickly before it gets rolled out to a bunch of applications, and B) I can see which applications are affected by reviewing the error reports in FogBugz.

Most of the changes that I make to my code library fall into the category of new functionality, as opposed to bug fixes.  I will often go years between updating a module in applications that don't change very often. I take a zealous (one might say paranoid) approach to backwards compatibility.  By taking that approach, though, I can confidently replace a module in an application even if it's undergone dozens of changes over many years since the last time I updated it in that particular application.  And even if it does break something, having the entire application under version control means it's usually pretty easy to see what caused the break.

Image by Free-Photos from Pixabay