That sinking feeling
It seems that nearly everyone in the IT industry has a story about the day they deleted, or at least nearly deleted, the most important thing in the world. For me, it was the time I arrived at the insurance company I worked for intent on clearing my working file, only to inexplicably enter the command to clear the company’s policy header file …oops.
While such events are relatively rare, they still occur, and as a result, IT departments have become well versed in managing their data assets. In fact, a great deal of effort goes in to ensuring that corporate database tables, source code, images, webserver configuration files, help, documentation and every conceivable bit of data is backed up nightly, weekly and monthly. Disaster recovery plans are implemented that involve large fireproof safes, offsite storage and may even involve replacement hardware running from a semi-trailer. In addition, everything is checked and double checked to ensure that, should the worst happen, the company can be back in business as soon as possible.
So there’s nothing to worry about…right?
While disasters are thankfully rather rare, there is another, all too subtle issue that plagues industry and IT departments all over the world; the simple software bug.
Bugs are unavoidable. They are a fundamental part of both development and day-to-day use of software applications. As Maurice Wilkes, the inventor of microprogramming, rather sagely said, “As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.”
While most bugs are spotted and resolved during development and testing, the odd one or two will make it in to production and may remain undetected for a very long time. Good ol’ Murphy’s Law tells us that they will likely exist in that really big program that’s been around for years, the one that no one likes to modify, but is continually tinkered with as new features are added or existing ones updated. You know the program. It’s the one that no one really understands quite well enough to be able to cut into smaller more manageable pieces. The one that just keeps getting bigger, and longer, and more and more convoluted.
Murphy’s Law strikes…again
Inevitably, someone will make a change to a piece of code, perhaps in a round of updates or just an emergency patch, which introduces a bug. If this occurs in one of the many traditional development environments where there is only one set of source, there’s already a good chance that the code running in production isn’t identical to that in the development environment. It may have been changed for a new round of updates. It’s also possible that the bug was introduced by a subtle change in the code as part a wholly unrelated fix.
Worse still, while the existing code is now wrong, there may well be no concrete evidence as to what the previous incarnation was actually like. Developers are left to talk to the user to determine the precise nature of the code before the new bug was introduced, in the hope that they can glean enough information to reinstate the correct functionality.
This example may seem to be a bit of a worst case scenario, but nevertheless, it is still quite commonplace. Many traditional development shops still use a single set of source that is maintained by multiple developers on a first-come first-serve basis. Code is locked by a developer who makes the necessary changes overwriting the previous version, a practice dating back to time when disk space was extremely expensive and developers used dumb terminals rather than PCs.
A solution for today
As the PC is now ubiquitous and storage is cheap, version control systems (VCS) offer a simple and effective alternative way of managing source. The model is really very simple. Every time an object is checked in to the system it supersedes the previous version, thus creating a complete historical record for the whole of the object’s lifetime.
When it comes to making changes, developers take a copy of the object to the development environment on their PC, and make whatever changes are required. This doesn’t require a lock of any sort, meaning that multiple developers can use the same source object and make concurrent changes if need be. While this “free for all” may sound a little strange, it is a very flexible development model. In fact, it is typically assumed that changes will be made concurrently, and version control systems provide merge and diff tools to manage these changes, something that is usually handled automatically as part of the check in process.
Using version control is a strategic choice, requiring an updated approach to development and is perhaps not for all sites. However, the benefits far outweigh any of the short term costs involved with setting up the system and the inevitable teething troubles as programmers adapt to their new environment. This is typified by what is probably the single most compelling feature of VCS; the ability to roll back to the previous version, something that is always rather complicated in a traditional development model.
Version Control in LANSA
Version 13 of LANSA saw the introduction of version control support. All LANSA repository object definitions, be they fields, files, functions, reusable parts or even images, are serialised as text documents. This allows for management in any version control system, be it one running on a local server, a distributed system managed by multiple machines or one of the growing number of cloud based systems offering subscription type licensing for as little as a few dollars per developer, per month.
In house software development is becoming increasingly diverse and complex. Package sizes and the volume of source increase year-over-year and businesses depend more and more on the availability and efficacy of their software systems. Version control provides an extra layer of insurance and security and ensures that “that sinking feeling” is a thing of the past.
