What Is ARS Object History?
ARSOH is a filter plugin which enables
Remedy administrators and developers to maintain a running history
of changes to ARSystem workflow objects in a centralized repository. The daemon is capable
of listening to events from multiple ARServer instances.
Target operating systems for the first release include all platforms that support java.
ARSOH is capable of supporting all
ARSystem workflow objects for which a Remedy server event is generated. This
includes forms, fields, form views, active links, filters, escalations,
containers (active link guides, filter guides, applications, and packing lists),
and menus. This does not include flashboards, flashboards data sources, flashboard
variables, flashboard alarms, DSO mappings, or DSO pools.
The main object audit daemon has the following characteristics:
Module 1: Object History Filter Plugin
The Object Audit Daemon captures changes to ARSystem workflow objects and stores the
definition in a central repository. A strain ID will be created for each object
to uniquely identify each object. The strain ID persists from the time of object creation to
the time of object deletion. ARSOH will compensate for name changes to workflow objects
using the ARSystem server events feature. Server events are communicated to
ARSOH through a configurable polling interval.
The user interface for repository access is accomplished using standard Remedy forms.
Information collected in the repository includes:
- Unique identifier
- Strain identifier
- Server name
- Name of the object
- Type of operation (create, set, delete)
- The object type
- User making change
- Timestamp of object change
- Definition of object at the time of change
- Revision counter
- Previous version unique identifier
The end user interface for this module allows viewing of the repository via
the Remedy User tool with methods to view:
- Objects changed per user
- Objects changed for a date range
- All revisions for a given object
Why Such a Program?
There are several reasons behind the development of this program:
- All too often, Remedy applications flex to the needs of the business in a way that is not conducive to the maintenance and administration of an application.
- When things go wrong and applications stop working, fixes are implemented on the fly, and no record of what or how is retained.
- During the application upgrade of purchased applications, reimplementation of customizations is cumbersome due to one or more of the following:
- No record of customizations were generated or retained, either technical or functional
- Vendor provided objects were modified and no method of identification was used to differentiate which objects were changed and which ones were not
- When working with a series of workflow objects, and things just aren't going right and you need a way to go back in time with all the objects you modified
- The available alternatives are clunky and cost prohibitive in terms of productivity:
- This program is to the alternative what CVS is to RCS or a complete lack of control
- No more checking in and checking out ARSystem workflow objects
- No more object locking
- Outside resources perform customizations and cry foul play after the engagement when things stop working (yes, this works both ways).
- Outside resources are brought in to provide a solution and the level of technical documentation required for future maintenance is inadequate.
- A better way of administering AR System Servers is long overdue.
Future Plans
The future direction of this program is speculative at this point as new and better
ideas come along, but the targeted extensions are listed below. The object history
daemon will serve as the underlying framework for the following modules:
Module 2: Requirement Management and Developer Check-in
This module will track, per functional requirement, various
information pertaining an enhancement, module, or workflow change. In addition to tracking
requirements, this module will enable each developer to check-in to a
requirement under active development. By checking in to a requirement,
all changes made by that developer can be tracked and correlated with a
requirement. This will in turn automatically generate and maintain a packing
list that includes all the objects created and modified to meet each requirement.
This type of information is important for tracking bugs and during application
upgrades. The information to be collected, per requirement, includes:
- Requirement Specification (The what, who, when, and how)
- System Generated Technical Documentation (The objects created, modified, and deleted)
- Administrative Documentation (How to keep healthy, administer, integrate, and extend the module)
- End User Documentation (Step by step instructions on using the feature)
- Testing Documentation (Step by step instructions and requirement validation points)
Module 3: Release Management, part 1
This module will serve to track releases of the tracked enhancements
(see module 2). The planned level of granularity for revision control will be four
levels (i.e., version 1.0.3.1):
- Level 1: Application version compatibility release level (HD 5.0 vs. HD 5.5 vs. HD 5.6)
- Level 2: Module specific release level (major overhauls, rewrites)
- Level 3: Functional release level (changes or additions to functionality)
- Level 4: Reactive bug fixes (corrections to improper code)
This module will also seek to meet these requirements:
- Ability to extract the definition files of a requirement for any revision level.
- Conflict tracking and resolution. Identifies objects modified by two or more developers under the guise of two or more requirements between release cycles.
Module 4: Release Management, part 2
This module will seek to extend the capabilities added by module 3 by
adding the following capabilities:
- Ability to move specific enhancements between environments.
- Ability to perform backwards environment refreshes of both the ARS application and the repository.
Module 5: Repository Integrations
This module will seek to take advantage of revision systems available,
both commercially and through the OSI. The purpose of this effort is to offload the revision storage from the ARSystem
Server to a system designed to act as a code repository. The specific
version control systems under consideration include:
- Subversion
- CVS
- PVCS
- Visual SourceSafe
Module 6: Application Integrations
This module will seek to use external applications as the gateway for bug tracking and requirement management. The
specific products under consideration include:
- Remedy Change Management
- Remedy Help Desk
- Bugzilla