I am including below a brief overview of "YaM" that we have developed
and have been using for 3-4 years in a fast-paced, concurrent software
development. The best way to think of YaM is as a s/w development
framework with a supporting toolkit. I bring it up because some of the
ideas, and perhaps even the code, underlying YaM might be of use to
those interested in a higher level process/framework for software
development.
While we have been very happy with it, it is clearly not a finished or
polished product. There are extensions and several loose ends that would
be nice to take care of. If there is an interest in it, I will pursue
the adminstrative steps to get my organizations blessing to make the
code publicly available.
=============================================================
YaM Overview
We have developed a framework and toolkit, YaM, designed to meet our
needs for rapid, concurrent development of software in a team
environment. The tool is written in Perl and uses CVS for version
control. YaM provides a range of higher level commands to support the
creation of development sandboxes on branches, their updates during
development, and merging and releases.
We use Bugzilla for problem tracking but have not attempted to tie it
directly to YaM. However I see no reason that it could not be done
especially since they are both written in Perl.
Main challenges that YaM has been designed for:
===============================================
* By its very nature, the s/w development process involves immature
code and fast and iterative changes. This mix in the context of
concurrent development can cause developers to break each others' code,
causing frustration and instability in the development process.
* Typically, individual developments focus on specific areas of the
overall code at any given time. However, the remainder code is needed as
scaffolding to support this development. As the size of the code grows,
the scaffolding setup and maintenance can add significant cost and slow
down the development pace, and can at times lead to a forking of the
development process with expensive sync up costs.
* Multiple s/w configurations are needed to support multi-platform,
testbed, subsystem, debugging etc. development needs, but are rarely
supported adequately because of the focus on the final delivered
product. This lack of s/w configurability creates a drag on the
development process with developers left to fend for their own day to
day development configurations.
Key design elements of YaM are:
===============================
* YaM is written in Perl and is organized as a set of utilities on top of
the public domain CVS software version control package.
* All development software is organized into a collection of "modules".
* YaM "packages" are defined as sub-collections of the available modules.
* Developers can set up private sandboxes for module/package development.
* All module/package development takes place on private CVS branches.
High level YaM commands support the setup, update and release of modules
and packages.
* Released and pre-built versions of modules are available to developers.
* Developers can tailor the source/link module mix for their sandboxes so
that new sandboxes (even large ones) can be built up easily and quickly
by pointing to pre-existing module releases.
* All inter-module interfaces are publicly exported via links.
* A minimal, but uniform, convention is used for building modules.
Benefiits of YaM:
=================
Some of the ways in which YaM has helped us deal with the challenges of
rapid, concurrent development are:
* The use of private CVS branches allows the isolated development of immature
code and helps avoid premature interactions and instability. YaM
provides a higher level layer to simplify the use of branches and hides
messy details from the user. The main trunk is used for releases while
branches are used for development. YaM's simple interface to the
management of branches helps keep them short-lived and avoids
the difficulties that arise when users directly work with CVS branches.
* YaM supports a module release area so that new sandboxes (even large
ones) can be built up easily and quickly by pointing to pre-built module
releases. Thus the developer need only checkout source code for the
modules under development, while the scaffolding can be quickly
generated by pointing to pre-built released versions of the remaining
modules. This saves considerable time, eases the creation of sandboxes,
enforces the clear definition of inter-module interfaces and promotes
code reusability.
* YaM makes co-developers into users of one's code, so that there is
continual I&T during the development process rather than relying on
expensive, system level I&T efforts. It promotes the "grass grows taller
as it is grazed" principle or software development. It helps catch
problems and bugs early in the development process.
* YaM promotes a "release early, release often" style of development
without jeopardizing development stability.
* Besides supporting the day to day needs of developers, YaM also
supports the versioning and configuration management needs of I&T.
* YaM encourages a clear and public declaration of inter-module interfaces
and dependencies, which is essential for minimizing hidden interactions
that are difficult to debug and isolate.
* The package concept inherently relies on module re-use. Thus code
reusability is an essential feature of the YaM development process.
* YaM provides much greater visibility into the functional breakdown and
organization of the software.
* YaM provides ways to generate quick sandboxes for testing, training and
demonstration purposes.
* YaM supports multi-site, multi-platform builds, and provides a clean
interface for using third party tools.
* YaM's use of Perl and CVS simplifies porting to multiple platforms (Unix
and non-Unix).
>>>>> "Cees" == Cees de Groot <[EMAIL PROTECTED]> writes:
Cees> We just closed an evaluation of source management systems, and the good
Cees> news is that we are sticking with CVS, Rational ClearCase lost the race. One
Cees> thing we learnt, though, from talking and reading is that a lot of ClearCase
Cees> customers take the time to define a process around the product, supported
Cees> by shell-scripts, triggers, and whatnot. We feel that we want to do the
Cees> same to CVS, so I am currently busy writing a shell around CVS (in Python)
Cees> that offers an activity-based interface to the repository. The user typically
Cees> won't say "I want to create a branch", but rather "I want to start working
Cees> on bugfix xyz" - the shell will take care of branching, deciding when and
Cees> what to merge, etcetera. I'm also planning a close integration with the
Cees> bug tracking system we use, Bugzilla (so that a developer can click a button
Cees> "Start work on this bug", which results in creating a branch etcetera).
Cees> I'll be selling this internally as an ideal candidate for an open source
Cees> solution - after a bit of initial hacking, I'd like to drop the stuff on
Cees> SourceForge under a BSD or GNU license. Now I cannot promise that I'll be
Cees> able to pull this through, but it would help me if there would be lots
Cees> of interest to actually use this stuff in the CVS community. Would
Cees> people consider/like to/love to switch to a more process-based shell
Cees> around CVS? Or is the general feeling that this sort of stuff ain't
Cees> necessary?
Cees> --
Cees> Cees de Groot http://www.cdegroot.com <[EMAIL PROTECTED]>
Cees> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
Cees> Forge your CipherSaber and list it: http://www.xs4all.nl/~cg/ciphersaber/
--
Abhi Jain
JPL, 4800 Oak Grove Drive, Pasadena, CA 91109
