Imagine a Caché Studio where you can keep track of your versions of routines, see who in your local network has them checked out for editing and get messages when things change or become available and you will have a sense of the simple, intuitive and logical interface of TrackWare.  Last night we heard a presentation, which gave the reasons and history of version control and ended with a simple demonstration of this powerful tool.

Jorma Sinnamo has a long history with MUMPS, NEMUG and the Boston area.  He helped set up NEMUG in the early days around October of 1989 when working in Boston but later returned to his native country of Finland.  Finland has an active country-wide M and Cache Users community but because of geography they have just two full day meetings per year.  These include presentations and ‘how to’ sessions that share members’ experiences.

To begin, Sinnamo gave an overview of how we have come to understand modern development practices and version control of software.  It grew out of hardware configuration management, which started in the military during WWII.  At that time, it was essential that standardized parts were available to fix equipment.  They needed to be available for preparation and readiness in adverse conditions. We use that concept now to manage software changes, revisions and releases.  As we know, software is very malleable and management is necessary.

In the analysis of times before management and software controls, problems with how things were run are immediately apparent.  There was a duplication of work and fixes that were installed on site were lost when next the release came out.  The question of how to maintain and keep track of multiple versions in use by the install base also came up.  Finally if the worst occurs and the system fails, what if there is nothing to go back to if development goes wrong?

The controls provided by Software Control Management has thus become seen as a necessity.  First of all, we know software changes all the time.  It is common to have to handle team development and groups working currently with the same code base.  Shared knowledge and support of teams in diverse locations has meant a streamlining of the process leading to more efficient development.  You have higher quality software and happier customers.

One necessary feature of configuration management is the human intervention.  There needs to be agreed upon processes and rules for behaviors.  One important component is a change review board (CRB) where decisions are made on users’ requests for change and the projects that will actually be worked on

What are the elements that need to be managed?  There is the code, the data, and the various other items like text files, images, specifications and now even business processes.  With Intersystem’s Ensemble system, end users have the power to change business rules, so even at the sites of installation there may be a need for a verification system.

Moving on to the TrackWare solution, the basics are this:  A software library stores the Configuration Items such as those listed above, i.e. the files, diagram and processes etc.  TrackWare then keeps track of changes made through reservation and replacement operations.  This is where programmers check out code and check it back and all these transactions are followed and audited.  The audit trail keeps track of what changed, by whom and why.  By backing up library all your systems are backed up.  The system also provides the ability to organize software into logical sets to help with the management and distribution of releases.

Sinnamo gave two examples of different development environment setups.  In the first scenario all programmers access one application of Caché through a shared namespace on the development server.  All workstations are off the same server and everybody sees the same system. The problem is the feature of this setup - all programmers use the same namespace and can step on each other’s work

In another scenario, you can have local development environments off of one server.  Each programmer has a local Caché environments, which means everyone has her own development space and other’s changes can be fetched from the library when required.

Next Sinnamo did a demonstration of his product and how it can work with either scenario.  He started with the bare bones green screen command line format.  He typed in some DCL-type commands which listed routines, profiles and identified the status of various elements.  For example, he went into Caché Studio and changed and filed a routine.  Then the terminal showed the routine, the status and the changes that had been made.  The integration with Studio is nice – the most commonly used version control functions are accessible there and update TrackWare directly so the developer doesn’t have to think about it too hard.

The command line can be used to build scripts, run daily audits, or a weekly refresh and can verify the software in use against the library.  The command line is not very pretty, but it is powerful.  There are also many shorthand mechanisms such as macro commands and profiles that make this part of the system still efficient and easy to use.

After this, Sinnamo switched from the command line to the client graphical user interface in color and windows. It’s a lot sexier.  It is also in a familiar environment, very much like Caché Studio.  Many management functionalities are visible and accessible on one screen.  Most importantly, updates made on other clients, through the command line or in Studio are displayed immediately. A monitor utility is also available with an alert to keep everyone in the office or LAN notified when changes are made. 

This is a simple approach that works easily for developers.  In addition, internal auditors at banks love TrackWare as they can see what has happened in the systems being run.  It seems to make the best of both worlds, programmers need for flexibility, ease of use and control and auditors own need for management, tracking and their own controls.  We look forward to more products from GlobalWare.