configuration management

There was a time when mainframe development was the norm and teams were in close physical contact only having to walk down a few feet to interact with their colleagues. However, times have changed and access to code has to be considered in a much more serious manner. Some companies have had multiple sites participate in their development efforts for upwards of two decades, but a majority of them have only been at this for the last 5 years or just undertaking this venture. The crux of distributed development is the ability to share code for development across sites via the network or via tape or disk.

My product is ready on CD. It's better than the previous release in respect to both quality and functionality perspectives. Does that mean it's ready to be released as a production product? How do I know when it's really ready?

It was 1978 when I first introduced change packages (a.k.a. updates) as the central feature of an in-house CM system. It's still in use today supporting a 40 million LOC project. It was 1982 when I introduced the concept of streams to rationalize branching along the product roadmap. Little did I know that a quarter century later, these concepts would just be starting to move to the forefront.

To get to our destination, the road that we take is important. In order to navigate, the road must be built for our needs. In order to keep it safe, signs with meaningful messages must be added along the way. This should parallel our approach to configuration management (CM). The road in this CM example is the CM infrastructure: a combination of the CM environment (CM technology and systems) and the CM procedures. This car vehicle is the project which uses CM road to deliver a release to its destination. The signs on the road are the organizational policies and direction given to guide us in the right direction and on the right road.