"Configuration Management", or "Version Control", describes the technical and administrative control of the deliverable components. It applies particularly where components need to operate together to provide the overall solution. There will be thousands of components in the overall solution - each one must fit.
Configuration Management may be applied to all version-controlled deliverables, for example:
More typically, it is thought of in respect of the various software components of the technical solution. Corresponding but less technical procedures would be used for Documentation Control.
All deliverables may have different versions as they pass through various stages of development and revision. Software components often have multiple "latest" versions. For example, different versions of a given item might be in use in the current live system, also be under test as part of an update project, be under revision by a programmer in the development environment, and be having updates from its external supplier applied to the baseline version. Each of those four versions could have variations in the way it connects with other related components.
As well as the tracking the status and nature of multiple versions, there needs to be control over their access and usage. It is a common error to find two people have separately updated the same thing. Whoever finishes last gets the changes applied. The other changes vanish.
Another common mistake is to assume wrongly that you already have the latest version to work from.
It is easy to make mistakes due to poor version control. What is worse, because the developers did not think they were affecting the "lost" content, they might not realise that it needs to be re-validated in the testing. Errors can easily be released into the live system.
The main rule is, therefore, only one person should have the ability to update a controlled item at any one time. The library system should "check out" an item for update, and "check in" the item when the work has been completed, checked and approved for update. Various access and authorisation rules will be applied to ensure people follow the procedures. You should make sure the controls are enforced physically with password systems, discrete environments, etc - but remember to allow for those operational emergencies when the library's owners are unavailable in the middle of the night.
The precise mechanism will vary. Tools are often specific to a particular software environment. You might find you need more than one tool where the project involves a combination of technologies.
Configuration Management does not form a major part of the Project Definition work. You would probably agree that suitable procedures and tools must be used.
If the project uses an existing software environment, the organisation should have suitable procedures and tools in place. If not, you should evaluate your needs and acquire appropriate Configuration Management tools.
Configuration Management tools will not normally be required until the Project Team starts working with the software. Early development work may not require version control where individuals have discrete parts of the system to work on. When the different components begin to be fitted together it is generally helpful to have them subject to version control.
By the time that components are ready for formal, controlled testing, an appropriate set of procedures and tools must be in place. Formal testing has to take place in a controlled environment, otherwise there is no proof that the components being tested have not been subsequently changed - which would invalidate the testing.
At the start of the work, Project Team members need to be briefed on the system and its importance.
Operation of the Configuration Management / Version Control process might be a Project Office task, it might be a designated role within the development sub-team, or it might be a specific service within the organisation's IT department. The custodian of the Library would administer the process, although good tools automate most of the work and allow "self-serve" subject to predetermined authorisation and procedural rules.
It is helpful to understand the migration of software components between various environments or contexts. Software projects are normally undertaken in such a way that incompatible activities are separated from each other in different environments. One way of doing this is to have completely separate equipment for each environment. There are also many ways in which differing logical environments can co-exist as part of a single physical environment.
The minimum requirement for control is normally three environments:
Other environments might be desirable. Project Managers often debate precisely how many environments you should have. Obviously, each new environment means additional resources and control overheads. Some of the other common environments might be:
This diagram shows a typical flow of released components. The Configuration Management system would control the migration. Note how the development team might need to work on components that are currently released for testing or already live. They would check out the live or test version of the component but would not be able to check it directly back into the live environment without passing through appropriate testing.
Configuration Management is a continuing process that will be required for the full operational life of the system. The procedures, information and tools would be handed over to whoever has on-going operational responsibility for the support, maintenance and enhancement of the system.