Longacre Deployment Management for Enterprise Configuration Management


working together it is common to find that they have different-sometimes radically different-work flows. This may be because the teams have different technological backgrounds, or because the teams originated in different companies, or because they are geographically widely separated. The need to quickly unify diverse teams is an excellent opportunity for implementing LDM. The fine process details of the individual teams can remain essentially unchanged, while an abstract veneer is developed that implements LDM at the enterprise level: the team knows about and uses two different test steps, but everyone outside the team knows about a single "Testing" phase in the change order life cycle.

When this standardized work flow is finally agreed upon, it will likely be more complex than the illustration above. For example, many teams want two states: "our team is not done" and "our team is done but the next team hasn't started." This is usually a good idea-it doesn't cost anything extra, and it does help to find some of the disconnects between the teams. Having "In Development" and "Development Complete" states doesn't confuse anyone. The work flow will be abstract, and these extra states facilitate automation of the work flow-extra state transitions mean extra chances to invoke trigger scripts.

Note that LDM does not lose information in this conversion: the locations are encoded as data, rather than metadata, but still recorded. The difference is that rather than having "Functional Test" and "Regression Test" be states in the change order life cycle, the two (or more) test servers are created as location records, and the changes are connected to these records by bundle records and deployment records. In fact, since a single change order could be deployed to a server environment, then removed, then deployed again, LDM can actually gain {C}{C}{C}{C}
{C}{C}{C}{C}information compared to a traditional CM technique.


In the illustration, the linkage from the change order to the various Locations is through the Work Items. This is deliberate, and reflects the fact that the change order objects do not correspond directly with changes to software. Instead, they indicate the need or permission for changes, and the requirement to test those changes. Changes to the software are directly associated with the lower-level work item records. This way, if the initial work done is not sufficient to effect a change, then a second (third, etc.) work item can be added to the change order until the requirement is satisfied.

One interpretation of the two sets of bundle and deployment records in the illustration above might be deployments in two different technology domains. (LDM discourages this: bundle and deployment operations should be technology-agnostic if possible.) A different interpretation is that the bottom line of blocks (Work Item through Regression Test) might be an early set of changes. Possibly this early set of changes appeared to address the change order, but testing on the Regression Test server showed some problems. Two new Work Items were created, bundled together, and have been deployed as far as the Functional Test server.

Keep in mind that there will still be metadata items in the system: LDM does not eliminate the change order life cycle. What changes is that the states that correspond specifically to places in a development process are eliminated in favor of a simpler, more abstract set of metadata. In development terms, this is a refactoring of the development change request life cycle, and of the development process.

ITIL CM vs. Traditional Software CM
Traditional software CM is based on tracking versions of files. This version-centric focus colors nearly all discussions of software CM in both obvious and non-obvious

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.