FAQ #21

Faq

What is Configuration Management?

Answer

Configuration Management

For the purposes of this article configuration management is discussed within the context of managing software. Where it is more commonly known as 'Software Configuration Management (SCM)' and exists as a part of the broader systems engineering configuration management process that is applied to any system that is being managed.

SCM Within a Project

Any project that is managed according to a process framework such as ITIL, CMMI, Six Sigma etc, will have roles and processes assigned for the purpose of managing such projects. In fact for some organisations it will not be possible to supply them software unless you are certified as being part of one of these frameworks and are compliant. In all of the process improvement frameworks 'Configuration Management' is defined as an integral part of any software project. Therefore project managers should understand why it is there and what exactly it is?

At this point most articles you find will write some sort of definition regarding a description of Software Configuration Managament (SCM). Most of which just serve to confuse the issue and once read provide no further insight. This article will explain in pragmatic terms what SCM is and why you would want to use it within your projects.

Take a look at this diagram, it illustrates a typical project that applies a process improvement framework. The user roles, processes, project milestones and project documentation are all well defined and each process and use role is documented.

cmProject.png

During the projects lifecycle a person carrying out his work as part of a role will produce various project assets, these could be things such as requirements documents, test plans, source code etc..

Software Configuration Management (SCM) is concerned with the 'things' people create as part of their assigned role. SCM will be involved in defining what should be produced and when, it will manage the naming conventions used within the project, provide access to the resources in a secure way and manage versions and baselines.

As the project progresses from milestone to milestone these assets will be changed. Some will be added, some will be frozen and subject to a change management process. For instance the project charter once agreed should not be modified after a certain milestone has been reached. SCM will ensure the rules around these process are enforced by providing evidence that the charter document has not changed or if it has a 'Change Request' was issued and signed off.

It is important within a project to separate the project assets from the developed software assets, and to be able to link the two together in some manner. Again SCM can help to ensure this happens.

With these concepts in mind lets look at how SCM is typically implemented and how it achieves its goals so as to add value to a project and the product being developed.

 

SCM Implementation

Consider some of the requirements the project members will have on the project.

  1. Access to project and product assets
  2. Safe retrieval and storage of all assets
  3. Management of changes to those assets
  4. Security with respect to who can see certain assets
  5. Management of software versions including 3rd party libraries
  6. Identification of what assets are required at each milestone
  7. Project conventions (how the project is laid out, how to name assets)
  8. Project reporting by use of audits (what was changed and why)
  9. Versioning and baselining
This is just a short list of what a project needs during its lifecyle.

SCM provides the solution to deal with these requirements? It does so by providing a central storage repository for all these assets. In short some SCM software is needed that fulfills these requirements.

SCM Software

A number of software solutions exist for SCM some commercial and some avaiable as OpenSource. The most common enterprise solution I have seen and used is Rational ClearCase from IBM, a complex and expensive solution which really requires training and experts to be available for it to be utilised efficiently. The OpenSource community has a number of offerings and I have experience with three of them.

  • CVS, outdated now and being phase out of most organisations, CVS has had its day and really does not provide a good solution for SCM.
  • Subversion, gained popularity from its introduction in 2004 as a replacement for CVS, became a standard top level Apache project, does not include change management but otherwise is a good solution and is used commercially as well.
  • Git, created by the legendary Linux creator Linus Torvalds for managing the Linux kernel source. Git is a distributed system and has now gained critical mass in its usage world-wide. A nice elegant solution for using as a SCM

SCM Software Concepts

The following diagram illustrates the concepts for all but most of the SCM software solutions you may encounter.

Checking In/Out

cmsNetwork.png From the diagram you can see that a master copy of the project and product assets are stored on a server that is running the SCM software. This is called the repository server. Each project and software product will be stored on this server and logically separated within the filesystem. The storage for each is called a repository but for the sake of argument this is simply a top level directory that contains accounting information about the file versions and access control lists that contain information regarding users and permissions.

You can also see that each user has a connection to the repository server and has also checked out a copy of the project or product assets. Getting a copy in this way is called 'checking out'.

Most SCM software does not concern itself with who has checked out what, as long as the user is authorised to get a copy it is given. However, when a user makes changes and wants to publish them back to the server then the SCM server is involved and checks what changes have been made and creates new versions of what has been changed. Pushing a copy back after changes have been made is called checking in and committing your changes. During this process the user will be prompted to enter a comment describing the changes he has made.  

Dealing with Conflicts

Now the more astute among you will realise that a situation for conflict might happen if everyone is accessing a master copy.

scmConflict.png

For instance it could be the case where a team member checks out a document, then another team member also checks out a copy of the same document. Now they both have a 'copy' of the same file. Then they both make changes quite separately of each other, in fact the second user does not even know about the first users actions.

User two (after making her changes) checks the document back in, some time later.

What happens to the changes? Does the change made by the first user get lost by being overwritten by the second user?

This is one of the reasons why you use a SCM, the SCM software will inform the second user that the file she is working on is no longer up to date and sends the new version for her to check for differences since it has now changed.

Some communication is made between the users and an agreed merged version is created and checked in. The diagram on the left illustrates the scenario This is known as a conflict, all SCM systems can handle conflicts.

Versions & Tagging

What are versions, and what is tagging? Consider the following diagram...

versions.png It illustrates a typical workflow interaction with the SCM server.

A users checks out a project consisting of three files.

He makes changes to the fileset and commits at various times during the day.

After more changes he finally he manages to get a tested working version and checks in. He also creates a tag on the SCM server at this point.

Then finally he makes some more changes, checks in and goes home.

From the illustration we can see that the SCM server is managing versioning, and that the user can create a logical name (an alias) for a set of versions (a tag). All very useful behaviour.

Of course at anytime a tester or another developer can check out the tested working fileset at the correct versions by requesting the tag my_tested_woring_v1 from the SCM server.

A version is a managed repository asset (file, document, image...) at a particular stage in its development. The history of a file is all its versions.

A tag is a symbolic name for a set of files.

Branching

What is branching? Branching is exactly what the word means, consider a tree, a branch is a diversion from the tree trunk. SCM branching is just the same.

The main area for storage of your files in the repository is known as the trunk, as with all things computing there are other names for this area, HEAD, MAIN LATEST, master. See the following diagram...

branches.png So what is happing here? Well we have three areas of interest.

  1. The TRUNK which is where the stable code is kept
  2. The DEV branch which is a copy of the TRUNK at a point in time
  3. The FEATURE branch which is a copy of the DEV branch

So we can see that a branch is just a copy of TRUNK or another branch taken at a point in time.

In our previous diagram we can see that the files copied from TRUNK were tested and working (check the version numbers), a STABLE set of files. In fact we copied our set from TRUNK to the DEV branch using the tag set by the developer in the previous illustration. We always like to keep our the TRUNK versions stable and fully tested.

So now we have a set of copied files as another branch named DEV BRANCH. These can be developed further and tested without affecting our TRUNK BRANCH. A very useful feature. Most commercial software houses use this method and developers are only given permission to check out from the DEV BRANCH.

The DEV BRANCH is not as stable as the TRUNK BRANCH, it is used for bringing in new functionality, and for testing fully before being merged back to the HEAD BRANCH.

We also have another branch called the FEATURE BRANCH, a copy of the DEV BRANCH, this is used to add some specific functionality (a new feature). The name of this branch is usually related to a description of the feature being added.

Our developer now codes the new feature and carries out his tests to prove that it works fine. When he is ready the FEATURE BRANCH is merged back to the DEV BRANCH for further testing.

Once the merged back code on the DEV BRANCH is tested and verified, it is merged back to the TRUNK BRANCH.

Configuration management within a project deals with these types of strategies and the method of branching and merging will be defined early on in the project. In fact it is the configuration manager job to specify the branching strategy that will be used and it will be documented within the Configuration Management Plan.

The branching strategy shown in this illustration is just one of many that exist, each suitable for differing purposes and lifecycles for project and product management

Note:
Please note the version numbers used in the illustration are just that, fabricated for the illustration only. Each SCM Server Software will specify its own versioning policy.

A Word About Change Management

Change management is a dicipline that is quite separate from configuration management. However some commercial SCM systems also offer or can be linked with a change management system so that any changes made in the SCM Server Repository can be linked to the change management Change Request (CR) this can be a useful feature. It can also be enforced with some of the OpenSource SCM servers by using scripts on the server that prompt for the CR number and add it to the check in comments.

Conclusion

This short article gives the reader some insight into what configuration management is and what part it plays in the project/product development. In essence it ensures the stability and verification of any system being managed.

Date Entered2014-06-08

Categories

21Configuration Mgmt

Comments

Not comments found