It all started with
Version Control (VC). A way was
needed to track first changes to individual source files, then to sets of
source files, then to sets of metadata associated with those source files, and
finally to sets of non-source files. It grew from a simple system to something
that can track changes to just about any file type and in a variety of ways.
Then came Defect
Tracking. Again, it started out simply and then grew. Along the way the need to
track Enhancement Requests and Issues was added forming what I refer to as DIET (Defect, Issue and Enhancement
Tracking) systems. Not too long after they started appearing, it became highly
desirable to be able to link the changes managed by the VC system. The files
and their revisions were kept in the DIET system as a part of the appropriate
DIET Records. This in turn required the VC systems to know about DIET Records
and to be able to execute updates to external systems when files and/or their
metadata were updated - thus the creation of wrappers and triggers.
About that time,
Graphical User Interfaces (GUIs) became popular, both for end-user applications
and for the CM tools used to manage their development. Both VC and DIET tools
went through the GUI evolution along with operating systems, applications and
user expectations. To complicate matters, the need for heterogeneous platform
support from both VC and DIET tools complicated things.
Up to this point, most
of the development had been by commercial vendors such as DEC, PVCS, MKS,
Softool, Aide deCamp and others (including the forerunner of ClearCase). They
were either based on earlier works such as SCCS and RCS, or on totally new
development concepts to meet specific needs. The transition to wrappers and triggers
was simple compared to producing either usable GUIs or heterogeneous platform support.
While this was going on, other needs started being addressed:
- Build Management (BM)
- Integrated Development Environments (IDEs)
- Languages such as PowerBuilder and Gupta
- The need for both VC and DIET systems to track
"promotions" of software from one state to another.
Build Management tools such as the various flavors of make
started appearing and being refined. Even though there was the GNU make
available for most platforms, it did not meet the specific needs of individual
platforms nor did it handle all languages well. Two approaches started being
developed:
- Automatic creation of "build scripts," generally
proprietary in nature. These scripts could then be captured by the VC system
and tracked along with the code they built. In most cases, the scripts
generated would be programming language independent and the builds would work
with only minor tweaks on most supported platforms.
- Tracking of build artifacts as a part of the
DIET system. The "build number" associated with each build, especially
successful builds, would be tied to matching DIET Records. Depending on how the
DIET system was implemented, the Records might appear as a hierarchy of
dependent records or as simply a linked list of associated records.
IDEs were more of an
issue as not only the CM tool vendors got into the act, but the Development
tool vendors did as well. Since one got the Development IDE "free" with the
compiler, the CM tool vendors had to struggle to integrate their products into
each of them. And there was no standard on anyone's part, Development or CM. It
is thanks to Microsoft that we had even a hope of a real solution with their
Source Code Control Interface (SCCI) standard. Of course, it was not an open
solution which kept Open Source development to a minimum and it did keep
changing as Microsoft felt the need, so one release of a CM tool might only
work with a limited set of releases of Development IDEs. When an organization
used Development tools that required different release levels of CM tools to be
compatible, many started creating their own "interfaces" using whatever
mechanism they could. Since many IDEs also started bundling a Build tool, the
ones that the CM tool vendors had integrated often failed to work and they had
to start creating "compatibility modes" or lose an entire market niche.
And then there were
the specialized languages such as PowerBuilder and Gupta, though they were not
the only ones by any stretch of the imagination. They were, for the most part,
interpreted languages that came complete with their own IDE and "build" tools.
The use of external CM tools was not even possible in the beginning other than
by versioning massive "composite" files or databases. Eventually, CM tool
vendors and the language vendors came to an uneasy alliance and things got
better again.
The concept of
Promotions came about from the desire to indicate which builds, and the
associated precursors, were at what stage of the Development Cycle. Classic
states include, but are not limited to, Development, Component Test,
Integration Test, System Test, Release Candidate and Production. These stages
correspond to the states a record could be "promoted" to in the DIET tools.
Additional states were normally added for failures at each "forward" state.
With the increasing integration between DIET and VC, it became necessary for VC
tools to at least recognize the promotion states and be able to "pull" code
based on those states instead of just tags or branches. Build tools also had to
be able to distinguish changes in the actual method of building deliverables
based on each promotion state. As an example, a fully debug enabled incremental
build could be performed for the Development state, Component Test and
Integration Test builds could do instrumented non-incremental builds and System
Test builds could do optimized, non-instrumented, non-diagnostic
non-incremental builds. Subsequent states could just copy the controlled System
Test deliverables to the appropriate physical areas with no additional work
performed. Of course it is also possible to do just one build - the Development
build - and then just "promote" it through the various states just like the
code and DIET records are.
Promotion mechanisms
and their associated audit controls and "design" tools created something that
was called "Workflow Management." It first became a part of the DIET tools and
through them spread to the other CM tool components. Everyone had their own
flavor and enforcement level. Of course, to be enforced the tools had to become
integrated and share some common functionality. VC tools had to block
non-Development level check-ins and Builds had to know what revisions to pull
when controlled items were in mixed states. This made cross-tool integration
more difficult than it had been in a long time, if ever.
About the time things started working again another cluster of
events occurred:
- The Microsoft Anti-Trust suit ramped up and
allowed Linux and Free/Open Source Software (FOSS) to get a foothold in the
Developers' hearts and minds. This was especially critical to the development
of the Apache Web Server and the Mozilla browser, and the associated tools that
were created to produce and maintain them.
- Sun introduced the Java language.
- CM tool vendors start being bought and sold to
create portfolios or suites of tools that encompass the entire Development
Cycle. Several of these tools are bought by Development tool vendors as well
for similar reasons.
- There was an increasing number FOSS offerings in
the VC, DIET and IDE arenas. This may have been due to the increased need for
such offerings, or it may have been due to the increasing per-seat cost of the
commercial ones, but the net result was that there were more choices than ever.
- Requirements started being taken seriously by
the CM tool vendors to the point that several new offerings were created, each
using a different paradigm. Some were document centric, others based on
database models. Some had support suites available, others were just
stand-alone tools.
Especially with the
advent of Requirement Tracking tools, I won't call them Requirements
Engineering (RE) tools since they
were too primitive at that point; we started seeing integrations such as
StarTeam (to name just one). This allowed Requirements to be traced to Issues
and Enhancements, which in turn could be traced to code changes made to
implement them and finally to Test Suites that could validate that the
requirements were satisfied. But one had to stay within the StarTeam approved
third-party tool integrations to be able to make things work properly. Adding a
non-supported tool was a major endeavor, though the presence of APIs did make
it possible. This was true of the other suite style tool kits as well and all
of them were commercial products with significant per-seat costs.
Finally, the ability
to customize workflow steps to match corporate processes allowed for fully
functional Workflow Management. Coupling this with the other integrations as an
enforcement mechanism is that I call an Application Lifecycle Management (ALM) solution. With every additional
component, every additional function, every additional capability, the ability
to pick and choose one or more IDEs, VC, DIET, BM and/or RE tools to create a
customized solution became more difficult if not impossible. Today we have
suites such as CM+, MKS's offerings, Rational Suite (with and without UCM),
StarTeam and others as proprietary solutions. They are even good solutions if
they match your corporate culture and process needs and if you can afford them.
Finally, there is Eclipse and its plugins. Currently, Eclipse and its ALM
project, is the only FOSS solution that intends to allow the creation of custom
suites with minimum custom coding. I look forward to seeing their progress
during 2007 and beyond.
Ben Weatherall is currently based in Fort Worth, Texas where
he practices Practical CM on a daily basis using a combination of CVS
and custom tools to support a modified Agile-SCRUM development
methodology. He is a member of IEEE, ASEE (Association of Software
Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG
(North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).
Trackback(0)
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed