CM Journal Articles SCM Techniques #4 - Longacre Deployment Management & Project Baseline
|
Patterns are a well-understood concept in software
development. Thanks to Steve Berczuk and Brad Appleton, they are a part of the
SCM vocabulary as well. So far, the SCM pattern vocabulary is relatively
low-level, concentrated on describing repository layout, branching strategy and
the like. The techniques discussed here are not patterns-they don't have the
required structure, and don't provide prescriptive formulas for implementation.
Instead, these are discrete, recognizable methods of software development or
software configuration management.
Configuration management is a discipline that connects to every single part of the software development process. This means that CM affects all parts of software development, but it also means that every part of the process impacts the configuration management activity of a project. Many of these techniques aren't purely configuration management-as if there was such a thing. Instead, they are techniques that have a high impact on CM. Adopting these techniques may help your project overcome certain CM challenges. Making radical changes to address a single CM issue generally isn't a good idea. But understanding these techniques can help you contribute to shaping the future direction of your project. This series will talk about twenty-two techniques, from five categories. Here they are. Ceremonious Techniques Automated Enforcement of Standards Gated Workflow Codevelopment Techniques Communal Development Distributed CM Independent Development Paths Interface Management Simultaneous Development Construction Techniques Component-Based Development Service-Oriented Architecture Software Product Lines Organizational Techniques Change Control Board System Architect Work Flow Techniques Fast Feedback on Changes Longacre Deployment Management Project Baseline Parallel Streams I totally blew it last month. I got my "Dimensions of SCM Challenge" article turned in, but chasing after work got in the way of writing an article for this series. I apologize to you, the readers, for missing that delivery. Rather than publishing "yesterday's news, today," I'm going to move ahead with the techniques for this month. The Journal is focusing on release management this month. To me, that means the delivery and deployment of released software. We'll be looking at two techniques on that theme. The first, which I call Product Baseline, is to release management what Monolithic Development is to build management-the ‘default' way to manage project releases.
Much current software development is built on technologies
that are simply not amenable to managing via the Project Baseline approach.
Longacre Deployment Management resolves most of the problems with
managing database schemas, metadata, and tracking the deployment of changes to
specific target environments. If your project doesn't have discrete "release"
events-like most IT projects-or if it includes a significant database
component, LDM is likely a better approach.
Each baseline serves as a jumping-off point for subsequent
changes in two different ways. First, a baseline serves as a snapshot of one
particular aspect of the product development process in time. A software
release is a frozen image of one particular software configuration. A
subsequent release will be built on the earlier baseline, with the addition of
certain changes. In addition, a baseline serves as the end result of one phase
of the project development cycle. While the frozen requirements 1.0 serves as the
foundation for requirements 1.1, it also serves as the starting point for design
1.0. A single project using Project Baseline may partition itself into subprojects as appropriate. Baselines can be set for individual sub-projects or across the entire program. Obviously, subproject baselines will increase the management load. The benefits of partitioning a large project into subprojects will outweigh this, however. Project Baseline has the advantage of being obvious. In an environment using formal project management techniques and with an organization divided into functional units (development, QA, etc.) the creation of baselines that correspond to defined milestones within a team and to releases between teams is an obvious step. Project Baseline is harmonious with a highly-structured organization, and fairly obvious to all members of the team. Because Project Baseline derives from formal project management, it is not tightly coupled to any particular software development approach. This high degree of abstraction lets Project Baseline serve any kind of development project, software or not. A combined hardware/software effort, a circuit board, or a commercial "shrink-wrap" software product can all be managed using the same approach. This abstraction leads to another advantage-independence from any particular technology. Project Baseline can be implemented using the latest and greatest tool suite, but it can also be done with a stock of loose-leaf paper and a #2 pencil. The last advantage of Project Baseline is independence. The formal nature of the technique means that the development activity can take place independent of the configuration management activity. This means that a single CM specialist can support a large development project, or support more than one project. By focusing on the "interface" between development and CM-the delivery of agreed-upon baselines-there is no need to tightly couple the two activities. Probably the biggest single disadvantage of the Project Baseline technique is independence. In my travels, I have encountered several clients with a separate, formal "CM team" that is totally disconnected from the development activity. As a result, the development team generally doesn't see any of the benefits of CM, and the CM team generally has no idea what is happening within development. Because of the long intervals between baselines, and the pressure for the CM activity to be more efficient (by supporting multiple projects, or using fewer personnel) the records maintained by CM tend to become very coarse-grained. This reduces the value provided by CM, and can hamper certain project management activities. It can also lead to a loss of respect for the CM team or the CM function. This sometimes results in development managers building their own private CM activity, followed shortly by reorganizations and terminations in the old CM office Because of the high level of abstraction, Project Baseline tends to treat the development process as a black box. This can disconnect the CM activity from other development activities, as mentioned above. In turn, this lack of connection and communication leads to reduced transparency and reduced traceability. The CM activity, properly a part of the project or program management office, cannot provide the kind of status and traceability information needed by other activities within the PMO. Naturally, the other PMO activities will pursue their information through other means, resulting in a CM function disconnected from both development and project management, and a messy, informal network of connections supplying the various project managers. There are no particularly onerous prerequisites for implementing Project Baseline. Instead, it is important to choose an implementation approach that is as simple and supportable as possible across the entire organization. It makes little sense to have multiple, slightly (or completely) incompatible implementations throughout the enterprise. Project Baseline provides value, in part, by encapsulation. There is no good reason for different implementations, save to correct errors, and those should be corrected everywhere.
The other significant requisite comes from the periodic,
black-box nature of the Project Baseline technique. Delivering baselines
requires a concrete result. This usually leads to a requirement to export or
externalize all the elements of the project. Sometimes this can be satisfied by
a bill of materials detailing the exact revision numbers of the individual
files, or the specific label in the system. But the complexity of the baseline
mechanism will tend to increase as the complexity of the project increases.
Hardware and firmware projects may have to include hard copy of the components.
Projects with a heavy database component may have to render all database
changes as a set of executable scripts (that are rarely ever executed, leading
to the obvious reliability problems), and project metadata may not be
expressable in any reasonable fashion. The point is that some kind of
archive is required for storing the various baselines, and given that different
baselines may be expressed in different ways-as source code, design documents,
requirements specifications, circuit layouts, etc.-the archive needs to be
fairly general-purpose. LDM implements a relatively standard Task-based Development pattern to collect and process change requests, and associate them with tasks and changed artifacts. Completed tasks are grouped into bundles-deployable containers-and deployed to locations-servers or server clusters. The relationships between tasks, bundles, deployment records, and locations provide the status accounting data usually recorded as lifecycle metadata. LDM was documented (in painful detail) in this article. Most development projects maintain a set of environments-development, test, staging, production-that match their CR lifecycle. As a result, two teams with different hardware budgets will generally have different CR lifecycles, making it difficult or impossible to merge the two processes. This has a predictable impact on co-development attempts. LDM separates server hardware from CR lifecycle. As a result, a single LDM lifecycle can support multiple development teams, with different hardware budgets and different development work flows. This design feature of LDM was originally aimed at different technology stovepipes in an enterprise application project, but it can be adapted to support geographically distributed projects, or ‘blended' projects with teams from different organizations. The defining advantage of LDM is support for database schema and/or metadata development. Because the bundle objects are related to work items (tasks), the connection between task and actual work is abstracted. This means that a task might be connected to a set of file versions, as is traditional, or it may be linked to a database transaction. Thus, any kind of database operation that can be usefully extracted can be bundled and deployed. The separation of life cycle from work flow permits CR data to be stored in a single, unified repository. This facilitates reporting at the project level and above, and gives all team members a coherent view of the project. In addition, separating change work flow from CR life cycle means that LDM can provide much more accurate data on the status of changes than other techniques. (By contrast, any system that conflates life cycle "state" with work flow "location" will mis-report one of the two for any CR that loops backwards after, say, failing a test. LDM requires a complex implementation. There are five main object types in the LDM model, as opposed to two or three in most traditional systems. The increase in complexity is linear, rather than factorial, since the object types don't interconnect arbitrarily. Nonetheless, implementing LDM requires a solid command of the life cycle modeling tool. In addition, LDM depends on the automation of many low-level operations. A full LDM implementation drives software builds, automated testing, SQL extraction and bundling, and software deployment across all targets from the object state transitions. The unified repository that is the source of considerable power for LDM can also be a drawback. Creating such a unified repository will have significant political implications, and will require data migration from other pre-existing repositories. The reliability and accessibility of the unified repository may be a risk, especially for widely-distributed project teams or enterprises. Supporting a distributed database can create a whole new group of database synchronization troubles. In these cases, strict partitioning of the database using some basic classification fields (database work in Dallas, etc.) is recommended. See Distributed CM for some discussion of partitioning a distributed database. The sine qua non of LDM is a tool that provides a customizable change request life cycle. Developing this capability requires climbing the learning curve for your chosen tool, or finding a qualified Subject Matter Expert. The implementation details at this level are critical. Implementing LDM may require performance- or functionality- related hacks or optimizations. As mentioned, Longacre Deployment Management requires automated support for all elements of the CR life cycle. The time and effort required to design and implement these scripts, across each development technology, will be a major cost driver in your LDM implementation.
LDM makes it possible to manage database data and metadata
changes in the same way as other software changes. Doing this requires the
ability to associate the changes with some life cycle object (‘task'), and to
automatically export database changes from the developers' database in some
form that can be deployed to other databases. If your database development
system does not provide this capability automatically, you may have to
implement it with a trigger, or by parsing the transaction logs. Austin Hastings has spent more than 20 years in the software industry. He has been a developer, system administrator, CM specialist, manager and consultant. Currently he is principal consultant for Longacre, a software CM and process automation consultancy. Austin lives in the southern part of New Jersey (the garden of the Garden State) but travels the world helping to keep software under control. Contact him at Austin_Hastings@Yahoo.com, or through CM Crossroads.
Set as favorite
Bookmark
Email this
Hits: 5481 Trackback(0)Comments (0)
|
| Last Updated on Wednesday, 28 May 2008 16:06 |
TrackBack URI for this entry
Subscribe to this comment's feed