Solving the Product-Line Problem
A single product is pretty easy to organize: Put it into a
single project containing all your files. It's also easy to version: simply
check it all in. And when you make changes, check it all in again. It's simple
because everything gets versioned together and all on the same schedule. Things
become more interesting when you create additional products and want to share
some files between them. Initially, it's often easiest to continue to version
everything together in one project, but as release schedules and goals for the
products increasingly differ, this becomes more and more problematic. And that
means it's time to adopt a product-line structure.
A product-line structure organizes files based on how they
are used. Each product gets its own project to hold its product-specific files,
while files which are shared also get their own projects. By giving each piece
of the products its own project, it becomes possible to share common components
as well as release the products on separate schedules.
Making the sharing explicit by putting shared files in
projects separate from the products which use them provides the key benefit
that the shared projects can be evolved independently of any product. The
products no longer need to use the same versions of the shared projects. Or put
another way, changes to a shared project do not need to be immediately adopted
by all users of that project. Rather, they can be incorporated at a time that
makes sense for each using product. In a large product-line environment,
separate shared project versioning is required for stability for products about
to release, while still supporting changes for products in development.
There is a downside to this organization though. It is no
longer so simple to version a product because everything needed by your product
is now spread over multiple projects. Branching, labeling, promoting, merging,
and other product-level operations must now operate on multiple projects. While
manageable when a product uses just one or two other projects, when it makes
use of a dozen projects, it becomes tedious and error prone (i.e. how can you
be sure you branched/tagged/promoted/updated everything?).
This then is the product-line problem: How to have a
product-line organization and gain the benefits of it, without losing the
simplicity and confidence of managing everything in one project.
A while back, SnapshotCM introduced the ability to mount
multiple projects into a single workspace. This provides the developer a
unified and seamless view of the product, even for products using a dozen
projects. The latest product-line release extends that unified view to
product-level operations like branching and labeling, promoting and merging
changes, freezing and creating new workspaces. The new release does this using
directed uses relationships between a product's primary project and the
shared projects which it uses. Operations on the product simply act upon all
components which the product uses, which improves productivity, reduces
mistakes, and instills greater confidence in the results.
Furthermore, the uses relationships are versioned so
different versions (snapshots) of your product may use different versions
(snapshots) of your shared projects. In short, this gives simple, big-picture,
product-level versioning while easily supporting project sharing and reuse!
The product-line release supports creating and editing the
product-line relationships, synchronizing the relationships to or from a
workspace definition, and navigating between projects using the relationships.
You can even create relationships between projects in different SnapshotCM
databases.
|
