Does anyone know of any GoodReferencesForBestPractice in CM?

Here is a random start...

• CheckInAndOutOften
• IntegrateOften?
• IfInDoubtTalkToTeamMembers?
• Always WorkWithYourOwnFilesPrivately?
• RegularlyUpdateYourOwnEnvironmentFormSharedEnvironment? (rebase?)
• TryAndAutomateAsMuchAsPossible?
• GetConfigManagementGoingEarlyOnTheProject?
• KeepBuildLogs?

And Bad practices are...

• IgnoreConfigurationManagement?
• LetTooMuchChangeBeforeCheckingIn?
• LetTooMuchChangeBeforeIntegration?

-- CharlesEdwards? - 16 Dec 2002

Table of Contents - (Generated automatically from sections below)

Good practices

Best practices are practices that are better than any other practices. Therefore, below you will find an overview of good practices. They may not be perfect, but these practices are good enough for many situations. Many CM tools support one or more of these practices.

Isolated workspaces

One of the primary functions of a development project is to make changes. For projects starting from scratch the changes are relative to nil, for other projects changes are relative to a previous configuration. Non-trivial changes involve (per definition) an amount of work that takes time to do.

During this timeframe, the current configuration a developer is working on may be instable. For this reason, the work (results) should not be shared with other developers yet. In other words, the workspace must be isolated from the rest of the team until it is stable enough (or ready) to share the results with the rest of the team.

For the same reason, changes from other developers, which may be stable themselves, should not be integrated in the workspace because this will confuse the developer about where problems come from. So again the workspace must be isolated. Only when the workspace is in a known state for the developer, changes from outside can be integrated.

Regular baselining

In general, software systems are rather complex, consisting of many files and directories with many versions. Only a limited number of combinations of those versions are sensible configurations for the total system. To keep track of what configurations are sensible, they must be made identifiable and reproducable. These configurations are called baselines.

It is good practice to make baseline regularly. This does not only allow "going back" to a sensible configuration from the past (for whatever reason), but it also supports the tracking of project progress.

Track changes through change sets

Although baselining is useful for finding sensible (usuable more or less stable) configurations, it is eminent that the question is raised: what makes this configuration sensible? The answer is that the difference with the previous baseline must make sense.

Since changes seldom involve only a single file, we need to know which changes belong together. For example, solving a bug may involve a number of files and adding a new feature may involve other files (or some of the same). To track which changes belong together, change sets should be kept. A change set contains the exact versions of files that belong together for the same reason of change.

Typically, the reason why versions belong together is some piece of work, also called a task or activity and sometimes (e.g. in RUP) called a work order.

Controlling configurations

Given a CM system containing a large number of file versions (e.g. thousands of files each of many versions), it is impossible to specify for each individual file which version should be used in a configuration. Maintaining such a list would be inpractical.

To make it easy, many companies just use the latest versions. Whenever someone checks in a file, it appears in all configurations. But this is a violation of the principle of isolated workspaces.

For isolated workspaces, a 3-layer configuration is working properly. As a basis for the configuration a baseline is used. On top of that, accepted change sets overrule the baselined versions. And on top of that, the developer's private changes overrule the baselined or accepted changes.

Note that "accepted" changes means that they are released by a developer (from his private workspace), accepted by the integrator (for use in other workspaces) and accepted by the developer (to incorporate them in his isolated workspace).

Dividing the system into components

Although a system can be considered as one single monolithical monstral consisting of thousands of file, it is often more useful to divide the system into smaller pieces, called components. Each components can then be used to set (and control) the configuration. By making components modifiable, read-only or invisible, a project can be organised into teams with limited scope and authority. This makes it easier to control large projects.

Early integration

It is a known fact that solving problems later is more expensive than solving problems early. For this reason, it is a good practice to integrate early so integration problems are found before they become expensive.

On the other hand, early integration means that parts of the systems are integrated while other parts of still under development. This means that some problems found during integration would not be problems for the final system because they are in an area that is going to change anyway.

Also, resolving integration problems while development is ongoing distracts the developers from their development work. This causes delays in the development work. When time is more an issue than quality (e.g. the system must be ready for demonstration), it may be better to postpone the focus on early integration a little.

Directory versioning

The directory structure in the archive may change over time. Other processes (e.g. build processes and makefiles) may depend on (absolute or relative) directory paths. Therefore, the directory structure must be versioned to be able to access the correct directory structure depending on the configuration that is selected.

Parallel projects

Parallel project on the same code base do add to the complexity of an organisation but they are good way to achieve shorter time-to-market. And for organisations doing maintenance projects and development project, parallel project are inevitable.

Allowing parallel project to exchange configurations (e.g. one project using a baseline of another project) sets particular demands on the CM system and the CM processes.

Tools supporting the good practices

Below you will find a table of CM tools that support at least 80% of the good practices.

Add more tools if you know they support more than 80% of the good practices

-- FrankSchophuizen? - 31 Mar 2003