A change can be viewed in two ways; conceptually or literally. What I mean by this distinction is that when I say the requested change is to “correct spelling mistakes in the poem” I am specifying conceptually what the change is to achieve (and after the fact, what the change achieved). On the other hand we are used to dealing with change in a more literal sense of as set of revisions, for example, “I edited file1 in this change”. In this post I discuss some of the issues and implications of these two views of change. Read the rest of this entry ?
Archive for the ‘Software Configuration Management’ Category
Toward a CM Ontology
May 22, 2010As I suggested in a previous post, I think the future of CM (and most especially SCM) lies substantially with the semantic web. My reasoning is simple; CM is about information management and this information needs to be shared, controlled and updated across increasingly more diverse organisations and systems. To provide this facility we need a lingua franca, a common means to control and consolidate information between disparate sources. The semantic web provides the means to achieve this information management and exchange.
The great advantage of semantic web over efforts such as the now defunct Application Lifecycle Framework (ALF) is that it requires no agreement between vendors (beyond using semantic web technology). The weakness of efforts such as ALF is always that they demand buy-in from the main tool vendors. A substantial number need to agree to develop and support the new standard.
Certainly semantic web is no panacea, but at least if Vendor A chooses one semantic representation of CM information and Vendor B chooses another they can still communicate by creating a correspondence rule set between the two representations (a little like XSLT can transform one XML into another — only a little though, semantic web has much more to offer).
So vendors need to agree to use and provide semantic web representations for CM information? No, not really. Most tools provide APIs that would allow this information to be interpreted from, or added to, any existing tool. Certainly a non-trivial effort, but one that is at least feasible. Better still, if multiple implementations are created for any tool these can again be consolidated using semantic web techniques.
The real power of semantic web technology comes from two sources; the abstraction of information semantics, and the ability to draw inferences from this information. Once you have an ontology, some inference rules and semantic relationships between ontologies, your inference rules will work across ontologies — neat. What does all the gobbledy-gook mean? It means that if Vendor A develops an ontology with a set of inference rules (rules for extracting more information from the underlying information) then Vendor B can map their ontology onto Vendor A’s and use Vendor A’s inference rules too. Actually it’s even better. User X can extend the rules and have them apply to Vendor A and/or Vendor B’s information sets equally, even if the original inference rules were designed for only Vendor A.
Brilliant. Problem solved then? Sadly, no. Although this all offers promise of a way forward there remains a lot of work to establish these semantic descriptions and, as many have discovered before, agreeing on the precise meaning of each semantic element is nontrivial in its own right. Not that this should stop us attempting the task.
Items have history
March 17, 2010As those of you who have been following this blog for any time will know I am currently looking in some detail at parallel development, specifically how it can be managed safely by non-expert version managers. I have used parallel development with much success on many projects but codifying my knowledge into a tool is proving challenging — and interesting too. In this post I will be considering item histories. Read the rest of this entry ?
In the beginning…
February 18, 2010…was the definition.
In this article I am going to lay out my definitions for some terminology that will become increasingly important as I develop my CMS model.
The terms I will be discussing are as follows.
- Stream
- Branch
- Configuration Item
- Revision
- Configuration
- Component
- Repository
- Configuration Management Database
- Record
At this point I caution the reader that these definitions are deliberately quite loose and informal. Each will be expanded, refined, rewritten and formalised as I work through articles in this blog. For now, my working definitions are as follows.
Project
A coordinated effort usually conducted by several individuals to deliver a Product. Project describes the totality of planning and activity requires to gather requirements and interpret these into Product.
Product
That which is to be delivered by a Project. Products include, but are not limited to:
- Executable software
- Documents — manuals, design documents, requirements, installation guides, administration and maintenance manuals
- Hardware — computers, network components, any other physical components required as part of the Product
- Training materials — exercise version of data or system components, trainer presenation, training the trainer material, sandbox systems for trainees
- Source code — when developing for a 3rd party. Source code may also be a deliverable in interpreted languages or when delivering web content such as HTML.
- Media — video, graphics, audio
Stream
Projects often consist of more than one piece of development. A common strategy is to manage these pieces of development as a sort of sub-project. Timescales of these Streams are overlapped to allow the project to compress its overall timescale.
Branch
An implementation technique used in development to manage simultaneous changes to common items. In software development Branches are common and used to allow two or more developers to work on the same source code simultaneously.
Configuration Item
A configuration item is an item within the configuration management system that is the focus for change management.
Revision
Each time an item is modified and submitted into version control, a new revision is created. In this way an item’s history can be traced by looking back through the sequence of revisions.
Delta
The difference between two revisions.
Configuration
A specific arrangement of item revisions.
Component
An item that is subject to version control, but is not elevated to the status of a configuration item.
Repository
A safe store for item revisions.
Configuration Management Database
A database containing information about each item revision and their relationships to one another and to records.
Record
A set of data that is subject to a process or workflow but not necessarily version control. Records normally carry information used to account for an item’s current disposition or the current state of a process or workflow.
CMS Tool: High-level architecture
February 11, 2010Continuing my musings about a universal configuration management tool I’ve drafted the basic architecture. This is summarised in the following diagram (after the break). Read the rest of this entry ?
Parallel development: theory and practice
February 10, 2010Having spent the past couple of weeks with a client working through the issues that need to be carefully considered when version controlling software, and in particular how to manage and control parallel development. I have come to three conclusions:
- People are often more afraid of the perceived problems than the practical realities of parallel development.
- People do not truly appreciate the problems and practical realities of version control and parallel development.
- There is a need for more theoretical work on the topic and, perhaps more significantly, a need for more formal expression of the process and problems involved.
- There is a quite substantial book that could be written on the subject.
Who’s afraid of the big bad merge?
February 1, 2010A common objection to using parallel development is the fear of the inevitable merging required to reintegrate the changes as the development proceeds. In this post I will take a look at some of the issues that arise from managing parallel development and, perhaps more importantly, provide some guidance on how to avoid the pitfalls of parallel development. Read the rest of this entry ?
Differentiating Configuration Items from Components
November 17, 2009Configuration management literature is replete with references to something called a ‘configuration item’ and most attempt to explain what a configuration item is. Despite this there remains confusion. “Should all files in my software system be a configuration item?” is a common enough question to raise concern that the concept of configuration item is not fully understood.
A configuration item is the unit of change for the configuration management system. A configuration item may consist of one or more other configuration items (sub-configuration items) and may also consist of one or more components. A component is always part of a configuration item; components cannot exist within a configuration management system independent of the configuration item hierarchy.
So, in software systems files are often only components. Configuration items within software systems tend to be larger entities such as sub-systems or libraries. The precise level at which you choose to identify a configuration item will depend upon where you want to exercise change control.
Software Configuration Management: An Investement in Product Integrity
October 1, 2009
For me, this book holds a special significance. This is the very first book I ever read that dealt exclusively with software configuration management. For me, this book started a career and lifelong passion for software product integrity and software configuration management in particular.
| Title: | Software Configuration Management: An Investment in Product Integrity |
| Authors: | Bersoff, Edward A.; Henderson, Vilas D.; Siegel, Stanley G. |
| Publication Date: | 1980 |
| Publisher: | Prentice Hall |
| Pages: | 351 (main body only); 11 (bibliography) |
| ISBN: | 0-13-821769-6 |
| Availability: | Out-of-print but available from specialist dealers |
| Amazon: | UK US |
| Price guide: | Varies widely. Reasonable condition copies can be obtained for ~£15 / ~$20 |
Review in a Nutshell
I maintain that this is still one of the best books written on the subject.
Review in Detail
As I said in the opening remark, this book was, for me, quite literally life changing. I read this book while working as a software engineer in the mid-80′s. Why? Partly from curiosity, but also because the team I was working on were looking to improve control on the product as we migrated from an old PDP-11 to a new MicroVAX.
That was my motivation, so should you seek out a copy and read it?
Who is it aimed at?
The book is aimed at a non-technical audience unfamiliar with software configuration management (SCM). This does not mean there is no value in reading the book if you are technically inclined or already familiar with configuration management. Far from it. I enjoyed rereading it recently and, even though it has been over twenty years since I first stumbled across this book in the underused library where I worked, I enjoyed being reminded of the fundamentals (with a twinge of nostalgia admittedly).
The book’s aim is to lay out the core principles of SCM and places them in the context of system development. This it does effectively. If you are looking for a step-by-step implementation guide then this is not the book for you.
Is it well written?
Bersoff, Henderson and Siegel write in a relaxed, semi-formal style that is easy to read. On occasion the walked through examples become a little laboured, but this may be a consequence of my familiarity with the subject. People reading the book early in their configuration management careers will find the detail helpful.
Does it cover the subject matter?
The book is divided into eight chapters:
-
Chapter 1: The Problem of Software
Where we are introduced to the nature of software and the problem to be solved.
-
Chapter 2: Managing the System Development
Configuration management is put into context within the system development lifecycle.
-
Chapter 3: Attaining and Maintaining Product Integrity
Lays the foundation for implementing configuration management.
-
Chapter 4: Configuration Identification
Explains the identification problem and lays out it solution within the SCM framework.
-
Chapter 5: Configuration Control
Explains the problem of change control and then proceeds to explain its implementation in the context of the configuration management plan.
-
Chapter 6: Configuration Auditing
Explains the problem that auditing addresses. Expands on the auditing principles and demonstrates them with a case study.
-
Chapter 7: Configuration Status Accounting
Explains the problem that status accounting addresses and the principles on which it is founded.
-
Chapter 8: Epilogue
Ties up loose ends and discusses the consequences of implementing configuration management.
These eight chapters cover all that matters in configuration management and places it into the wider system development context well.
The material discusses at length the documentation used in configuration management and some of this is a little dated. There is, for example, much emphasis on manual processing and little on automation. This is entirely forgivable given the paucity of supporting applications at the time the book was written.
The development methodology described in the book is, as one might expect of a book written some thirty years ago, based on a more traditional waterfall model. This should not, however, deter you from reading this book. The core principles remain sound and are easily adapted to any development methodology.
Despite the lack of coverage for support applications (such as change control systems or even version control systems) the principles are described well and almost all of the manual processes described are relevant to modern implementations of SCM even though we tend to rely more on databases, rather than manual paper records, to hold and process information.
What is missing?
Automation and the use of modern applications to control the SCM process are not covered for the obvious reason that they were less common in the late 70′s and early 80′s when this book was written.
This book, quite rightly in my opinion, is ‘bare metal’ SCM. There is no discussion of other lifecycle disciplines beyond that required to place SCM in the context of the system development processes.
While the book discusses some implementation issues it is not a guide to implementation. As such there is no implementation plan beyond a brief discussion of the configuration management plan.
Standards are not discussed, but any standards extant in the early 80′s would be superseded by now so this is no great loss.
Would I but it now?
So, would I buy this book now, knowing what I do?
Yes! Absolutely and without reservation. (In fact I did. The copy I recently re-read was obtained only six months ago from a second hand book seller on Amazon for the princely sum of fifteen of your English pounds sterling.)
Is Configuration Management the right name?
August 11, 2009Too often we see the name Configuration Management or Software Configuration Management applied to a team when in fact they perform a whole range of functions supporting IT system development. This has lead to a gradual bastardisation of the term Configuration Management to the point that the term has lost its original, focused meaning and has become, very nearly, a useless term. Worse, for the teams involved, their true function is concealed behind this increasingly broad term.
In Through the Looking Glass, Humpty Dumpty, when challenged by Alice over the meaning he assigns to the word ‘glory’, responds as follows.
“When I use a word,” Humpty Dumpty said in a rather a scornful tone, “it means just what I choose it to mean – neither more nor less.”
This is the situation we find with Configuration Management (and doubly so with Software Configuration Management). These terms mean whatever the individual using them intends them to mean and this results in a loss of communication (not to mention many warm discussions on forums as to what should fall under the purview of configuration management).
Surely it is better to return to an arguably more impoverished but more specific and focused definition and in so doing ensure that we all agree to the meaning. A new term should be found to represent the collection of disciplines that are variously bundled under the present configuration management banner. Configuration management must remain the discipline responsible for the identification, control, accounting and auditing of configuration information. Nothing less, nothing more.
The correct name for the collection of disciplines, including build, release, change, configuration, project management and so on, may be Lifecycle Management, Process Management, or any of a number of neutral collective terms, but not configuration management which already has (or rather had) a very specific dominion until it was expanded and, ironically, simultaneously eroded by the inclusion of odd disciplines.
The inclusion of another responsibility, such as build management, in the responsibilities of the team who perform configuration management does not automatically mean that that discipline becomes part of configuration management. What you end up with is a team responsible for both build and configuration management.
I propose the title “Lifecycle Management”. It encapsulates the various disciplines commonly found provided by ‘configuration management’ teams. It describes what these teams actually do. It is sufficiently flexible, capturing the idea that the team supports and manages the lifecycle concerns of a project, product, or organisation, but also allows room for extension.
So, Lifecycle Management shall, henceforth, be my profession.
