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
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
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]