Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

SCM: An Important Focal Point

Written by Neil Street

Sunday, 19 September 2004 16:00

There are many contributors to the successful deployment of a working system. Strategists, Architects, Developers, DBAs, Operations to name but a few and Software Configuration Management can be a focal point for them all. Recent experience has led me to reflect on just how important the relationship between all of the stakeholders and SCM can be and what can happen when that relationship is not well established at the outset of a project.

Here I will contrast the different experiences of two organisations embarked on similar development programmes in a J2EE development environment. I mention the technical platform because I believe that J2EE, possibly because of its emerging nature, poses challenges that could easily be overlooked.

Scenario 1

Right at the outset of the programme, all of the stakeholders are involved in specification so that all of their acceptance criteria are discussed and agreed. This was frustrating to the development teams who had already started to cut code and were frequently made to alter track. For example, it became clear at an early stage that the applications would be required to behave differently depending upon the environment in which they were operating. This is normally achieved by using configuration files to store the environment-specific information. A different version of these files would be deployed to each environment. A decision was made to standardise this approach so that all such configuration information would be delivered as metadata that would be processed as part of the deployment process. This involved the developers in a time-consuming re-work of their configuration files and additional training in the use of the metadata processor.

Many such decisions were made in the early stages of the programme, mostly as a result of an operational requirement being translated into a design strategy. In all cases, SCM was involved and was able to design the build and deploy tooling appropriately ensuring, firstly, adherence to the design strategy and, secondly, confidence in the satisfaction of the operational requirement. Put simply, this meant that those responsible for the operation of the production environment had confidence that their entry criteria were met.

Because java is a “late binding” operating environment, certain aspects of the build tooling required special attention. For example, it would be quite possible to build an application using one version of, say, a third-party XML parser, and run the application with another. The configuration and behaviour of classloaders often makes it difficult to appreciate that this is happening. SCM worked closely with the technicians that were responsible for the production environment to ensure that the build tool exactly matched the operating environment. Developers being developers, often little attention is paid to the precise versions and locations of resources in the workspace. Ensuring that the build tool matched the operating environment ensured that any such discrepancies were picked up early in the development life-cycle.

In summary, SCM served as a meeting place for all of the various stakeholders ensuring, through its own processes that agreements were adhered to. These agreements ranged in scope from design paradigms to file naming conventions. Absolute certainty that they are “designed in” by the SCM processes ensures confidence in the consistency and fitness for purpose of the delivered application.

Scenario 2

SCM is established as a function of the Configuration Services team who are responsible for setting up all of the formal test environments including infrastructure and database. The project has been running some time and, although all of the code is version controlled, SCM is not present in a recognisable sense. The first job is to wrest the build process from the developers and ensure consistency. This is made more difficult by the different ways that different development teams use the version control tool. The testing schedule dictates that, at least until parallel running has ironed out any glitches, the existing build process be continued.

Now that we are moving closer to a production release, more interest is being given to how the application will be deployed “for real”. There is no consistent approach to the way in which environment-specific information is dealt with – currently it is handled manually. There is no automated deployment tooling. A close look at the structure of the application reveals that there is no control over what code finds its way into the application. There are, for example, three different versions of a third-party logging utility contained within the application.

In summary, because of the lack of attention to detail at the beginning, the integrity of the application has been compromised. It is now very difficult to implement SCM processes that will guarantee the fitness for purpose of the application. The team who will be responsible for running the production environment have either never been consulted or, if the same Configuration Services team are to do it, lack the necessary skills to do so. In the short term at least, the project is doomed. Significant architectural changes will need to be made to enable good SCM processes to be adopted which will, of necessity, interrupt the development life-cycle.

The lesson that I have learned from these two scenarios is just how important the relationship between the SCM role and that of all of the other stakeholders in a project can be. SCM can add so much value by providing a framework within which all of the contributors can deliver in harmony. Without such a framework, something will surely be missed which will lead to expensive delay and rework.

Neil Street has worked in IT for more years than he would care to remember predominantly in the U.K. financial services industry. He has a background in software development and now provides consultancy in Configuration and Release management.

You can email him at nstreet@cix.co.uk.

Set as favorite

Bookmark

Email this