approach to software deployment than traditional CM techniques. "Bundle and deploy" is not the same as "build and release." Traditional CM focuses on configurations, and leaves updates to the configuration as a technical detail. LDM treats the updates as discrete objects and de-emphasizes the configurations themselves.
In traditional CM, the change order life cycle is a superset of the list of possible locations: a change order would move from (for example) the development state to the functional test state to the regression test state to the production state. LDM replaces this lifecycle metadata with simple data-location records. Rather than have states named after all the servers, or servers named after the states, LDM separates the change order work flow as seen by management from the deployment process used by build and release management. The work flow is simplified: a change order can be in development, or it can be in testing, or it can be finished.
At the same time, the individual work items that make up that change can be deployed to the development server, or the production server, or both in any combination. In the implementation, teams had either two servers or four servers, depending on what technology (Cobol, Java) they were developing. Neither two servers nor four servers correspond particularly well with the three parts of the simplified life cycle (development, test, production). But LDM glosses over exactly what servers correspond with what life cycle states: there is obviously a correspondence, but not a rigid equivalence. Instead, things that are being tested get marked as being in the "testing" part of their life cycle. And things that are deployed to the production server environment get bundled and linked with a deployment record indicating production deployment. If an urgent change happens to be tested in the production environment, that fact gets accurately reported.
LDM enables geographically, or technologically, or organizationally diverse teams to cooperate by providing a very simplistic change order life cycle and abstracting the lowest level CM details. A Cobol team on the top floor can cooperate with a documentation group in the basement and with Java teams in other parts of the world. What is needed is an abstract transport system to make all locations accessible, and a single repository for the LDM tracking objects (including the change orders and work items, or at least proxy objects for the work items).
Probably the most important benefit is that LDM is an enterprise CM technique. The complex development models that are becoming commonplace in today's multi-technology, multi-location IT shops put a significant strain on conventional build-and-baseline CM approaches. LDM abstracts the CM operations and process model at a level that is comfortable for both managers managers and engineers trying to enable and manage development in a complex enterprise.
Further, LDM helps to address one of the most difficult challenges in software CM: controlling database structure and content. Conventional attempts to manage databases focus on representing the database as a file or file-derived artifact, to be controlled in the same fashion as ordinary source code. LDM treats server configurations, including traditional software work areas, as though they are databases, and builds a CM solution on this abstraction. Rather than trying to select a particular version of a database, or table, LDM tracks the updates that have been applied. It is much easier to implement a pseudo-SQL ‘UPDATE filename.c SET version = "2.1"' for files than it is to perform any kind of version compare on even a medium-sized database.
In fact, the initial implementation of LDM controlled database structure and content, plus traditional components that were