Adavicity Configuration Management

 

Anyone coming of age in a Unix environment, and others who’ve taken the time to explore the roots of version control tools on other platforms, will be familiar with SCCS.  The Source Code Control System that is a part of standard Unix was arguably the first source code revision control system ever developed.  Today’s modern systems include Subversion, CVS, Clearcase, Visual SourceSafe, Mercurial, and Perforce.

 

Configuration Managers know that source control is at the heart of CM, but it’s eyes and ears are defect tracking systems.  These systems provide the framework for communication between the various groups working on a project.  Some such as PVCS Tracker are desktop applications.  Others, such as JIRA can be completed Web based.

 

The technical underpinnings of CM are contained within the ideas around the Capability Maturity Model and the Capability Maturity Model Integration which have garnered much more attention lately.  For non-academics, CM goals can be summed up as tracking software changes in such a way that the project continues to move forward, that this progress is captured and can be reliably recreated, and that all team members have safe access to all changes.

 

The Adavicity approach to CM is that of a programmer/QA/PM service, that helps guarantee correct code with a minimum of overhead on the part of these users.  CM helps all the talent work together.  Sometimes this means more work implementing processes that reinforce CM goals.  Sometimes CM has to pick up the slack that very creative developers need to do their jobs.

 


Adavicity  Configuration Management at Amtrak

 

Adavicity functioned in all aspects of Configuration Management, version control, writing production and development tools and release distribution in support of a major development project: the PSCC Train Control System and its expansion into New Jersey.  Adavicity also contributed to quality assurance and development of some auxiliary portions of the software and in troubleshooting parts of the graphical system.  At the CM helm, we supported all other departments with services and reports.

 

As keepers of the CM process, we created and enhanced the system by which software changes are requested, completed, submitted and incorporated into the release software.  Doing this required creating a simple process and the forms by which developers were able to notify CM when a change was completed.  The next step in the process was creating a report of changes outstanding relative to the current production system.  This report was used by the four stakeholders: Project Management, Quality Assurance, Production Support and CM in order to decide what would be included in the next release.  CM also created a release transmittal that described what was included and provided a basis for user alerts and training.  After the fact, CM could be counted on at any time to track where and when a particular change was placed into production.

 

Throughout, we administered and supported an object client/server version management system known as TrueChange from McCabe software. It operates on Unix and Windows, among other platforms.  The CM area merged over time with some Unix system administration tasks including automating startup of the application.  With one well-crafted tool on one machine, a new environment could be configured, and with one command it could be started on 40+ Unix workstations.

 

As the application grew, there were variations among the workstations which made maintenance more complex.  To solve this, Adavicity helped develop a “Unification” system that encapsulated all settings in one simple text file.  Machines could now be interchanged with a simple change of attributes.

 

Adavicity was able to develop a suite of tools to fully automated the build, release and distribution processes.  This suite of tools was written in ksh and perl.  Other efforts included restructuring the source file tree to eliminate duplicate code, instituting tracking policies, bringing all internal and third party software under source control and creating startup (“turnkey”) setup for the application on several platforms. 

[May 1997 through December, 2005]

 

 

Adavicity at the Philadelphia Stock Exchange

 

We wrote a popular tool using Unix scripting to regulate sharing of testing resources among development staff.

[September 1998 to March 2000]

 

 

At Health Information Technologies

 

Many times we are brought into a project for one purpose but in taking ownership we are often faced with doing many other tasks.  This was the case at HIT, where we were lead developers, but had to take on the task of controlling source code and deploying the built product.  The ability to automatically build all terminals with a specified version of code using PVCS proved invaluable. 

 

In this case it was the code for a medical claims processing point-of-sale device.  The POS system delivered claims from doctors offices to insurers. The MC68000-based devices communicated with a Stratus server.  That same system, in a different mode, usually in the middle of the night, could be used to transmit code updates in the other direction. We wrote the software to upgrade terminals in the field.

 

Additional tools were needed for production and shipment of terminals and for tracking by the customer service staff.  And yet other tools were helpful in the support of the testing environment.  Adavicity was there creating most of this in a PC environment.

 

Throughout, we worked directly with all departments to support claims capture and processing.  While innovated the design of new software we created a coding standards document.  We installed, configured and administered PVCS, Make, PC Lint, several editors, Novell’s Btrieve database and associated and third party tools, as well as several C compilers and many other programming tools. 

 [1990 to 1993]