to the structure and content of a relational database was the key issue when LDM was developed, and so database CM became the one essential feature. The simplest analogy is that traditional CM tries to control a database by treating it as a file, or a product derived from a set of files. LDM takes the opposite approach, and controls software configurations by treating them as databases. This may help explain why the normal vocabulary of "builds" and "releases" is missing. It has been replaced with collecting together (bundling) small changes, and applying those changes (deploying) to a particular target (location).
Work items are grouped together into Bundles. A bundle is an entity that records basic information about the purpose and origination of the bundle, and links to the work items that compose the bundle. Extracting each work item's associated changes from a repository and grouping them into a deliverable package is called bundling. A bundle is considered to be atomic-all the changes in the bundle must be applied as a unit, or none of the changes should be present. This is akin to a transaction in relational database vernacular. The tools that support task- or change set-based development generally support applying and removing these changes atomically, but at the level of individual work items. You will have to build on top of this to extend atomicity to the bundle level.
When one or more mutually compatible bundles are ready, they can be deployed. A Deployment, another entity,ties bundles to the Locations where they are present. The deployment records contain documentary data, traceability data, and links to the contents and the deployment target locations.
Locations are the end target of Longacre Deployment Management. A location corresponds to a server, or a database, or a workspace. Whatever mechanism you use to discriminate among different deployment targets, that is a location. Typically, a location will be a separate machine, or a separate workspace, or a separate database instance. Locations are data records that replace some of the metadata usually associated with status tracking in traditional CM techniques. Instead of creating a different status for each test server (functional test vs. regression test), LDM creates location records for each server, and connects the work items to the location records using bundles and deployment records. A location record is just a proxy for a server-a piece of equipment-so the lifecycle is centered around tracking the service life of the equipment.
Because the work item records identify the actual changes made to the system by developers, these are the records that are linked to the bundles. A bundle will be linked to all of the work items that are packaged together by that bundle. A bundle can contain changes (links to work items) that are part of different change orders. Bundles are independent of change orders. The connections between change orders and work items are unrelated to the connections between bundles and work items.
Think of a truck from a building supply store delivering to a construction site: the truck may deliver items for plumbing and items for electrical work. The truck probably doesn't contain all the plumbing items, and it probably doesn't contain all the electrical items-the plumbers or the electricians may call up later and request more stuff. But it can contain items from both categories. In the same way, a bundle can contain finished parts of more than one change order. And it doesn't have to contain all of the parts of any change order. Just whatever changes have been scheduled for delivery that day.
The LDM back end is a different