Properly organized and executed source code and related artifact configuration management are vital to the success of any development, regardless of idiosyncratic system architecture, development methodology, or implementation language. Practically, this means managing change: tracking changes to system artifacts in a coordinated way, communicating these changes to the people who need to know about them, and sometimes even preventing or delaying changes. Fortunately, there are many best practices in configuration management as it relates to workgroup productivity (I list several good books and Web sites in the bibliography).
Configuration management extends beyond promoting teamwork. In a component-based system, components usually don't work with all possible versions of other components . (Just ask your QA teamthey'll tell you about the ones they've tested , not every possible combination.) It's a lot easier for a customer or technical support to prevent or diagnose problems when components know their prerequisites. In message-passing systems, messages should have version identifiers so that changes in content or processing rules can be managed.
You need release management because your customers need it. They need to know which version of a system should be ordered and which is compatible with previous versions, the patches and/or upgrades that are available and which apply to their situation and in what order, and so forth. The issues are complex, both from the standpoint of the underlying technology and because some of the choices have nothing to do with the underlying technology, as I will describe later in this chapter.