 |
Change Control
return to Home page
|
| I've also had some thoughts on managing change control that I'd like to
share. This note is intended mainly for developers, and will probably bore our
subject matter experts to death. Since I wouldn't want to lose any of them,
especially this early in the project, they can skip this note, though of course everyone's
welcome to comment. Here then is a first cut at how we might want to use it to
manage code (or other documents), based on my experience with ENVY, the change management
tool that most large Smalltalk installations wouldn't do without. First, some terminology: Component: The building blocks of a system. For the Littlefish application, the components will be Eiffel classes, clusters, and the application itself. Containing component: A component that is built from other components. An Eiffel cluster is the containing component for Eiffel classes; the application is the containing component for its clusters. Edition: The state of a component that allows modifications. An edition of an Eiffel class or cluster can be changed. Multiple editions may exist at one time, as in the case where several developers are working on the same class concurrently. Version: The state of a component which does not allow change. Multiple versions of an Eiffel class, or cluster, or the application, may (and likely will) exist, but each version is unalterable. A containing component cannot be versioned until all of its contained components are also versioned. Release: The process of specifying that a versioned component is authorized for use within its containing component. Only versioned components may be released, and components may only be released to an edition of the containing component. Furthermore, only one version of a component may be released to its containing component at one time. The designation of released components to a versioned containing component cannot be changed; the designation of released components an edition of a containing component can be changed. Thus, for example, once a cluster is versioned, the designation of which versioned classes are released to it cannot change. Component ownership: Containing components have designated owners, who are responsible for the integrity of the components contained within. Only component owners release contained components to the containing component they own. For our project, each cluster will have an owner, and the application will have an owner. One person may own one or more clusters, while the application will have one owner (possibly also a cluster owner). Now, here are some procedures for applying these concepts. I have necessarily simplified the process that ENVY applies, since we won't have an automated tool (other than something like SCCS) to assist us: --To make classes and clusters available, we'll need an ftp site accessible to all. Each developer would have his or her own directory, with exclusive write permission, and read-only permission for everyone on the Littlefish project. In addition, we would need two directories for the application, each with a subdirectory for each cluster. One of the application directories would be for development purposes, with write access for each cluster owner's subdirectory restricted to the cluster owner, and read-only access restricted to Littlefish developers. The other application directory would be for general public consumption, containing the latest released version of the application, with write access for the technical manager, and read-only access to the world. Under this scheme, all classes within each developer's directory are considered to be versioned, but not released. All classes within the cluster owners' subdirectories in the development directory are considered versioned and released, while the clusters and the application itself are considered editions. All clusters, classes, and the application itself, within the technical manager's public release directory, are considered versioned and released. For convenience, we would need a Windows .zip or Unix .tar file, for both the development and public release application directories, that could be downloaded and expanded to the appropriate subdirectories and classes. --At the beginning of a development session, developers can "load" the latest released (approved) version of the application by copying (downloading) from the application development directory. Developers are free to work on whatever classes they need to, in order to accomplish the task at hand. Developers may also copy from other developers' directories, to obtain class modifications that are in progress but have not yet been released. --When a developer is satisfied with the state of modifications to a class, he or she copies it to his/her private directory, and sends a note to the cluster owner. The cluster owner reviews the changes, and if satisfied copies the new class to the cluster directory under his/her control, in effect releasing to other developers. Developers may also wish to copy class changes to their personal directories to share with other developers. Developers will, by convention, update the Indexing clause of the Eiffel class to indicate the date of revision, nature of the change, etc. --If more than one version of a class is submitted to the cluster owner at the same time, it is the cluster owner's responsibility to combine the changes from each developer's work into a final, acceptable and released version. The cluster owners' directories represent a work in progress, with the possibility that additional work may be required before the final product is ready. --When a cluster owner wishes to release a new cluster version for general use, he or she notifies the technical manager that a new version of the cluster is ready. The technical manager then reviews the cluster, and if it is approved, copies the current contents of the development cluster directory to the corresponding public release cluster directory. When the copy is complete, the technical manager notifies the cluster owner; until notification from the technical manager is received, the cluster owner is prevented from moving new class changes into the cluster directory. I hope this scheme is not overly complicated; my intention is to provide a procedure that would work for our geographically widespread group, without the assistance of a source control management tool like ENVY, while still providing sufficient control over the work we'll produce. I've neglected some aspects, such as how to obtain prior versions of components. If this is something the group feels might be necessary, let me know & I'll give it some thought. We could surely rely on a general purpose version control utility like SCCS, and some additional procedures, to obtain prior versions. Please feel free to comment. It's still early enough in the project to think about ways of managing mundane but essential tasks like change control. David Jenkins |