Today I got an email from a customer that they couldn’t enter information into a certain form and asked me if I had it locked.

Immediately, I knew I had messed up because I had made a change in my development database in which I changed that’s form recordset to Snapshot to test the behavior of an update routine that needs the recordset to be unlocked.

My deployment script is run from the development database and makes a copy of the development database and makes a few changes on that copy to run in the live user environment. This file with the bad recordset setting was then copied into the final deployment package and uploaded in my latest changes.

Once the user told me about the change it took me about 30 minutes to first change it back, re-run the deployment scripts, package the install file, log into their VPN, and put the new install file on the network.

But, how could this have been avoided? How could I change my deployment process so this wouldn’t have happened?

I use versioning software to track any saved versions of the system. Maybe I should not make a copy of the development system, but keep a pristine copy of the last live version of the database front end in a folder used by my deployment process. Then I could maybe change my deployment script to make a copy of the pristine live database and run updates from my versioning system on that. Then I should have my deployment script run unit tests to make sure everything works as expected, (I am using TDD to create unit tests for all expected user behavior, right? Uhh… yeah, I’m not there yet). But ideally IF I had fully functional unit tests that whole process would ensure that my live copy at least passed all my tests and had only the changes I had committed since the last time I deployed it.

I think having an automated deployment pipeline like that would have prevented this issue. Although, for the most part, this is a pretty rare circumstance for me where things like that make it into the live system. Usually I commit all changes and would have caught that before I committed it and changed it back from the test recordset setting I was using.

Sound like overkill? It might be. All this depends on the kind of Access application you have written, how often it’s really being changed, and how important it is to prevent unintended changes.

Do you use a deployment process for any of your Access programs?