... an organization is creating NamedStableBases, and developers can build against these versions, integrating their own code with the latest of other code (IncrementalIntegration).
✥ ✥ ✥
How can we balance the need for developers to use current revisions, based on periodic baselines, with the desire to avoid undue grief by having development dependencies change from underneath them?
It is important for developers to work with current versions of software subsystems to keep up with the latest enhancements, avoid running into already fixed bugs fixed elsewhere, and to avoid getting out of synch with interface changes.
Introducing new software into an environment while debugging may cause grief by introducing new behavior, and providing distractions because of the time spent resolving integration issues in some cases, code may no longer compile due to interface changes.
However, we must balance these needs: the need to keep up to date with the need of developers to maintain a stable environment for feature development/bug fixing.
Some organizations, to facilitate IncrementalIntegration, will have a shared baseline of code, libraries, etc. Unfortunately changing a code base, even in a different subsystem, can cause problems when there are interface changes, for example. You want to avoid hearing stories about developers leaving a problem at night to view it in the morning with a clear head, only to find that one's test environment does not compile.
Therefore:
Provide a mechanism where developers can maintain a PrivateWorld development environment. In their PrivateWorld they can control the rate of integration. This allows them to avoid having an integration step interrupt work in progress. The environment should represent a snapshot of all the software being developed in a system, not just the code the developer is modifying. Try to ensure that the private development area is not used as a means of avoiding integration issues.
✥ ✥ ✥
A starting point for the independent development area would be one of the NamedStableBases which have been previously released. Developers then build their software and any related software that depends on their software. Alternatively, you can provide the ability to do a private system build from source code (and other artifacts).
While allowing developers the freedom to decide when to allow changes into their space you need to make sure that the developers update their code as often as possible to avoid integration surprises. So encourage developers to integrate their code frequently, perhaps by providing a mechanism for easily backing out of a difficult change.
Depending on details of implementation, one consequence of this pattern might be that project disk space requirements may grow quickly as N developers will have their own copies of the source code. But the costs of personnel almost always exceed the cost of an extra disk. A modification to this approach is that stable and distantly related subsystems can be used by reference, but one should be made aware of when changes are imminent. In this case the configuration management system should provide access to prior NamedStableBases as well.
Developers can simply defer advancing to a new instance of the NamedStableBases until the current problem is solved.
A variation of a PrivateWorld is a shared integration machine. In this case the developers move their new code to a system that has a current version of the system.
The pattern simulates SoloVirtuoso. See also PrivateVersioning.
Example:
A developer is working on a problem. The developer work space is self-contained with all of the files needed to build the system. The developer work space is updated only at the developer's request, after the problem is solved in the context of the current NamedStableBases.
Notes:
Brad Appleton points out:
Sun's NSE (Network Software Environment) had this type of thing built into it. I think that the more recent TeamWare product may also have preserved some of these concepts. NSE let you create work spaces that it called "environments". There were three kinds of environments you could create:
Independent Development Environments: for Independent Development.
Independent Integration Environments: for integrating (importing and merging) and reconciling changes and integration building and testing.
Independent Release Environments: for release builds, system test, and other release engineering and software product deployment activities.
PrivateWorld captures the spirit of all these environments.
An environment would insulate developers but would not isolate them. There was an event notification and registration mechanism for broadcasting events in one or more other environments to interested parties (maybe this is a more general configuration management event notification pattern of which things like baseline publishing and change publishing are concrete variants).