Many years ago I was working on a Department of Defense project that had to conform to software development standard DoD-Std 2167 and software quality assurance standard Mil-Std 2168. The DoD was trying to grapple with the huge influx of software systems and programming languages at the time. These standards were an attempt to bring some engineering discipline to the part-science, part-magic world of system programming. At the completion of the project, I was thinking that all team members should be issued a t-shirt that read “I Survived 2167.” Since then, those standards have been superseded and even the language-to-end-all-languages (Ada) has also essentially been abandoned by the Department of Defense.
As it is with most everything else, the one constant of software standards is change.
A recent project assigned to me involved migrating several applications to a new environment. One of the toughest and most frustrating parts of the task was determining what applications were running on what machines and where the proper versions of the source code were. The revision control was nothing more than putting a statement in the application script to log the version number (a programmer-generated date/time stamp) into the runtime log file. Determining the runtime version required connecting to the machine, searching through the log file to find the last time the application was started and recording the date-time stamp information. I then went to the integrated development environment and opened the application to see if that information matched the entry in the source code. Even if they did match, it did not guarantee that the runtime was generated from this source or that this source was different from that used to generate the runtime, with the exception of the date/time stamp. of course.
Given this not-uncommon situation, I was asked to do a little research on revision control tools. I settled on Git—a distributed version control system, meaning that the client gets a full copy of the repository, all files, history, branches and anything else that is in the repository. I keep the project master repository on our server, where it is secure and routinely backed up. Prior to starting work or going to a customer site, I clone the repository onto my laptop and take it with me. I can make changes at the customer site, commit the changes if I like them, and then push the changes to the server when I get back to the office. I can then delete the local copy of the repository if I choose.
While my use of Git was viewed as something that might be workable, it was not adopted as a standard. However, I was permitted to use it on my projects, provided that doing so would not disrupt theprocess.
All of Git's capabilities are nice, but what dividends has it paid? Here’s a partial list:
* Git generated code difference files on a VB.Net project when the customer contacted me 18 months after the project was completed and wanted to know what changes were incorporated into two separate releases. As a result, it was a simple cut-and-paste effort as git listed the differences for me.
* Git allows me to give detailed log entries about what was changed and why. Many times I have tried to maintain a Readme.txt file in the archive folder, but that discipline usually falls away. Git makes it easy, showing me the files that have changed; if they are text files, git even shows the lines that have changed.
* Git can create a branch, allowing me to experiment with code changes. When those changes do not work, I simply delete the branch and revert to the original code.
Whether you settle on Git or a more traditional centralized version control system, it is a discipline that will benefit you and your company.
David K. Anderson is senior project manager at Loman Control Systems Inc., a certified member of the Control System Integrators Association. Learn more about Loman Control Systems on the Industrial Automation Exchange.