Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Collaboration Operations
Five basic collaborations operations govern the movement of assets from a workarea into the common staging area through the compare, update, and merge operations that integrate changes from other workareas to the publishing of an edition. These operations are shown in Table 1. Each operation is much more than merely copying a web asset from one place to another. For example, the movement of assets from a workarea is typically used by a single developer into the staging area that is shared by all affects the entire team. Just as we cannot help but interpret graffiti placed on a highway overpass as having a larger social meaning, each submission of an asset into the staging area makes an important social statement to the organization. The contents of the staging area represent common assets for the organization, and small changes can have a major impact. For instance, two days before a major release, a developer wisely decides to delay submitting "clean-up" Java servlet code consisting of renaming variables, reordering the subroutines, and reformatting the indent structure of the code. Success of the release depends on knowing precisely which old problems have been fixed and being able to isolate sources of new problems by focusing closely on recently changed logic. Development is collaborative, and a developer must always recognize the larger social context of the development effort.
Table 1 shows two main ideas. First, it describes five basic collaboration operations—submit, compare, update, merge, publish—and describes them in terms of the movement of assets between areas. Second, and more significantly, the table suggests an interpretation of each action in a larger social context of collaboration.
Table 1 Basic Collaboration Operations
|
Operation |
Description |
Interpretation |
|
Submit |
Copy assets from workarea to staging area. |
"To my esteemed colleagues, I have completed, tested, and have obtained approval for the following assets. They are suitable for integration into your ongoing work." |
|
Compare |
Compare assets in workarea with corresponding assets in staging area. |
"I'm at a point in the work on my task that I'd like to see the new and modified assets in the staging area, for possible integration into my workarea." |
|
Update |
Copy assets from staging area to workarea. |
"I believe that updating my workarea with the following assets will help me stay in closer synchronization with recently submitted changes from my colleagues, and hence enhance my ability to submit my changes when that time comes." |
|
Merge |
Resolve conflict between staging area and workarea. |
"I've modified an asset for which another colleague has also modified and has submitted. To keep my this asset synchronized with the staging area, and to enhance my ability to submit my modifications later, I will merge selected changes from the staging area's copy into my copy of this asset." |
|
Publish |
Create edition, which is a snapshot of entire staging area. |
"The staging area comprises a version of our web property that will be useful to us, either as a distinguished snapshot in time (such as an archival reference), or a potential rollback version of our web property. As such, I'm creating this edition." |
Submit Operation
Submitting an asset from a workarea, shown in Figure 3, presents the asset to the rest of the organization. It is more than a developer claiming, "I'm done." Instead, inserting the new or modified asset into the staging area is merely the first hand-off step in integrating the asset into the web property. With it goes a presumption that the asset has been sufficiently tested and reviewed, and therefore is suitable to be integrated into the ongoing work of the rest of the organization. A healthy organization demonstrates mutual respect by adhering to the convention that submitted assets are high quality, as demonstrated by explicit testing and peer reviews.
){kind=link}
Figure 3 A developer submits her changes to the staging area.
Compare Operation
The compare operation identifies new, modified, and deleted assets in the staging area, with respect to a given workarea. For example, a second developer might compare his workarea to the contents of the staging area (see Figure 4.) The possible comparison results are shown in Table 2. This gives a developer the opportunity to decide which differences to pull into his workarea. The comparison reveals a mixture of internal changes made within the workarea and external changes that have been submitted to the staging area by others. If external changes have a reputation for high quality, the developer will feel more confidence in readily pulling in changes. In the compare-update work cycle, certain specific differences might need to be resolved.
){kind=link}
Figure 4 A second developer compares his workarea to the contents of the staging area.
Table 2 Possible Comparison Results Between Workarea and Staging Area
|
Case |
Description |
Conflict? |
Possible actions |
|
1 |
Same version as in staging area |
No |
None |
|
2 |
Modified, based on version currently in staging area |
No |
Submit change from workarea. Revert to previous version in staging area. Merge changes into workarea's asset. |
|
3 |
Modified, based on different version than currently in staging area |
Yes |
Merge workarea with staging. Overwrite staging, to override conflict and submit workarea's asset. Force update workarea, to overwrite the workarea asset with asset from staging area. |
|
4 |
Deleted in workarea, exists in staging area |
Yes |
Submit deletion, to remove asset in staging area. Force update workarea, to undo the deletion in workarea. |
|
5 |
New in workarea, no corresponding asset in staging area |
No |
Submit change from workarea. Force update workarea, to discard new asset. |
|
6 |
New in staging area, no corresponding asset in workarea |
No |
Update workarea, to pull change from staging area into workarea. Overwrite submit deletion, to delete the asset from the staging area. |
Update Operation
Update is the collaboration operation that copies changes from the staging area into a given workarea (see Figure 5). When changes have consistently high quality, frequent updates to ongoing development are beneficial to the organization as a whole. Smaller, incremental updates with controlled disruptive effect spread the burden of integration over a longer period. This avoids costly one-time disruptions.
){kind=link}
Figure 5 Changes in the staging area that haven't been modified in the workarea can be updated into the workarea.
Merge Operation
Merge is the collaboration operation that resolves conflicts between a workarea and the staging area. (See Figure 6.) This takes care of changes that require more than just copying in. It is an essential part of achieving maximum productivity because conflicts need resolution before submission. Merging incrementally during development instead of deferring all merges until the last moment typically takes less time and produces less aggravation.
){kind=link}
Figure 6 Merging a change resolves the conflict with a previously submitted asset.
Publish Operation
An important collaboration operation is publish, which records a snapshot of the staging area, shown in Figure 7.
){kind=link}
Figure 7 Publishing an edition creates a whole-site snapshot of the staging area.
The key is to strike a balance between raw speed of development and the need to stay synchronized with changes made by others. These are two important factors that impinge on the development process, and it is important to take them into account when designing the content-management infrastructure.