Configuration Management Workshop
Who We Are
Steve Berczuk, — CM process definer at CoreChange
Ralph Cabrera, — CM tool for small projects developer/trainer at AGCS
Brad Appleton — CM tool developer/integrator at Motorola
Robert Orenstein — Technical writer for CM tool at Perforce Software
What We Wanted to Accomplish at ChiliPLoP™
We wanted to collect/write as many patterns as we could from contributions of the attendees. We also wanted to organize the patterns into a pattern language that would be useful to people who are implementing SCM in their organizations.

What We Did Before ChiliPLoP
We started collecting pattern ideas, or patlets, into what was called the L.U.M.P. document. LUMP stands for Lots of Useful Material for Patterns. This collection grew as we neared the ChiliPLoP date and peaked out around 100 pattern ideas. Along the way, we began putting the patterns into general categories like User Environment, Configuration Identification, etc. The categories and pattern placement were reviewed by the members of the team as the LUMP document grew and changed. Revisions were placed into (big surprise) a configuration management tool to track changes. Just prior to the conference, the four of us made sure what materials we were going to bring (research papers, books, tool manuals, et al).

What We Did at ChiliPLoP
Steve Berczuk proposed that we put all of the pattern ideas onto index cards and come up with broad categories into which we could sort the patterns. He also proposed that we determine what the broad categories were based on the end-user perspective. Our first day at ChiliPLoP was devoted to this activity. After some discussion and explanation of how useful the collection of patterns would be to the end-user, we came up with the following categories and the relationships between them.

Organizational patterns deal with solving problems at a group, department, or even company level. For example, if all the developers are at one location, there are patterns related to that setup. If the developers are distributed around the country or across the world, a different set of Architecture patterns may come into play.

Architectural patterns relate to the code and/or documentation structure that a project applies. Patterns like "Physical Architecture Follows Logical Architecture" address how directory hierarchies and contents are laid | out.

Forming SCM patterns are about those activities which occur once or very infrequently and tend to establish configuration management policy and procedure.

Preserving SCM patterns are about those activities which occur on a frequent basis (weekly, daily) and enforce or preserve the policies and procedures that were established by the Forming SCM patterns.

By the end of the first day, all the patlets were on index cards, the categories were assigned a color, and each patlet was reviewed with respect to the categories and tagged with the appropriate category's color.

Our second day began with identifying governing Organization pattern issues. We came up with a few that would help us understand the driving forces that organization would have on SCM. One example is Single-Site versus Multi-Site development.

Since our charter didn't really include Organizational patterns, and there was a separate hot topic at ChiliPLoP devoted to that, we decided to work at the Architectural level and downward. We met with the Organizational Patterns hot topic later in the conference and found that we will have a good source of patterns to fill in that level from the other group. Further work in this area has been identified as a future task.

We took the color-tagged cards, beginning with the Architecture patterns, and looked for relationships between them. Most could stand alone, some were variations of each other, and others were finer-grained detail. Relationships along these lines were represented by how they were physically grouped on a chart. If the cards were side-by-side, they were peers. If cards were placed on top but lower than others, they represented a level of detail lower than the cards above.

We processed the Forming SCM pattern cards in like manner, but also looked to see if some may be related to the Architecture patterns. We found that the Forming SCM patterns also were variations or finer details of each other. We related the Forming SCM patterns to the Architecture patterns if the resulting context of an Architecture pattern led to the initial context of a Forming SCM pattern. An example of this is the pattern "Change Control Board", whose resulting context of having a CCB leads to the initial context of establishing integration builds, found in the "Named Stable Bases" and "Incremental Integration" patterns.

The Preserving SCM patlets were the largest group of cards. Reviewing these cards produced relationships to the Forming SCM patterns. Some of the Preserving SCM patterns were related to Architecture patterns without an interconnecting Forming SCM pattern. This result showed us where we might be missing patterns.

The final day of the conference was actually a half-day. We realized that we had made a lot of progress, but now we had our work cut out for us. We spent the morning session planning what we wanted to do after the conference and presented this at the last conference plenary session.

What We are Doing Next

The team decided that we needed to have the work that we accomplished in a better documentation format than index cards pasted to flip-chart sheets. Steve volunteered to capture all of the pattern ideas, their categories, and relationships in a Microsoft Access database. Robert volunteered to capture the diagrams and relationships graphically. We hope that the result of both of their efforts can generate HTML pages for a web site.

Brad volunteered to provide descriptions for patlets in the LUMP that currently didn't have any. Ralph will assist Brad with this.

Brad and Ralph will fill in the database that Steve produces with the descriptions from Brad and the LUMP.

The team will be looking at other taxonomies in which the patterns could be represented (e.g., organizational levels, specific developer roles, etc.).

The team will be submitting a subset of the pattern language to PLoP '98. Brad may be representing the paper at PLoP. The sublanguage will focus on the change grouping and task-related patterns that bridge across organization, architecture, forming CM, and preserving CM categories.

The team would like to relate the SCM pattern language with the organizational pattern languages.

The team will be dividing up the existing patlets amongst them, converting the patlets into patterns, and passing the completed patterns around for review.

The team would like to recruit more participants for reviews, sources of patterns, and for ChiliPLoP '99.

Note: PLoP is a trademark of The Hillside Group, Inc.