Workspaces refer to 'private' areas where developers can implement and test code in accordance with the project's
adopted standards in relative isolation from other developers. The Configuration Manager needs to create a workspace
environment for each developer on the project.
A workspace provides each developer with a consistent, flexible, inexpensive, and reproducible environment that selects
and presents the appropriate version of each file. The workspace needs to be able to provide fine-grained control over
both sharing and isolation. This is required because in most projects, developers need to stay isolated from changes
made by others; but at the same time, they must be able to unit-test their changes with changes made by certain other
developers.
When performing maintenance on older releases, a developer needs to be able to see older versions, binaries, documents,
tests, tools, and other objects. In this case the workspace serves as a 'time machine', making everything in the
environment, not just the sources, appear as it did in the past.
Each developer's workspace needs to be isolated, for purposes of editing, compiling, testing and debugging. However,
the isolation of the workspace should be relative and not absolute:
-
Others should be able to track a developer's work and selectively integrate it into their own.
-
Others should be able to shut out. Until a subsequent integration period, those changes that may prove
destabilizing to their own work.
A workspace can be completely private to an individual developer, or shared among a team of developers over a network.
In addition to providing access to source versions, a workspace needs to provide private (isolated) storage for files
generated during software development:
-
Working (checked-out) versions of source files,
-
Executables,
-
Other workspace private objects - source code, test subdirectories, and test data files.
A workspace's private storage would be typically located within a developer's home directory on a workstation. A
workspace shared by a group of developers might have its private storage area located on a central file server.
However, the actual location of the private storage is largely irrelevant. From the developer's point of view the
workspace's private storage should appear to be fully integrated.
The figure above illustrates the notion of private and integration workspaces in the overall context of the CM Cube.
Working configurations (workspace profiles) refer to particular subsystems that make up a working set for the
project. A working set is a list of specific versions of subsystems that must be referenced, or modified, to
implement a piece of work. This list may represent the entire system or a subset.
A view provides access to a set of files in the project repository. Moreover, a view provides access to an appropriate
set of versions of those files:
-
A new development view may provide access to the most recent versions of the files.
-
Another new development view may provide access to the versions being used by a team working on a new user
interface for your product.
-
A maintenance view may provide access to the versions of the files that were used to build a given release of the
product.
A workspace, sometimes also called a view, allows developers to make and test changes in private before sharing the
modifications with the rest of the team. There are two types of views:
-
Snapshot Views
-
Dynamic Views
A snapshot view provides the developer with a stable, unchanging working environment. It is analogous to a
computer directory tree. A snapshot view is populated with copies of the appropriate versions of files from one or more
project repositories. Some people use the term "sandbox" for such a directory tree. When a developer wants to see
changes made by other team members, she updates her view. This style of working is characterized as a pull model
as it relies on actively pulling in the relevant information, rather than it being immediately available through
automatic refresh mechanisms.
A dynamic view is a virtual data structure as it appears to contain all the development data. Dynamic views do
not make local copies of files, but rely on over the network immediate updating. Dynamic views may be the best choice
in the following situations:
-
There is limited client-side disk space
-
You want to take advantage of derived object sharing
-
The development team must work with the latest versions of the code. This feature is particularly useful for
integration that requires the latest version of any given software.
|