h1

Preventing ticket ping-pong

February 27, 2010

This is the first opportunity I have had for a while to put something on this blog — busy, busy, busy. (I can tell you that I am building up a fairly sizeable backlog of articles on parallel development and I will, I promise, get round to publishing them soon.) In the meanwhile, here’s a brief thought on designing ticketing systems.

Many ticketing systems, supporting processes such as incident management, are prone to ticket ping-pong where tickets are bounced from queue to queue as people keep forwarding the problem to get it off their queue. This is simple to control once you see the problem. Read the rest of this entry »

h1

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.

h1

Fences and Ambulances

February 17, 2010

Suppose you are in charge of a cliff edge. Your task is to maintain the views from the cliff, but keep visitors safe. You can construct a fences along the top of the cliff, to stop people falling over, or you can place ambulances at the foot of the cliff, to clear up once someone falls over. Read the rest of this entry »

h1

CMS Tool: High-level architecture

February 11, 2010

Continuing 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 »

h1

Parallel development: theory and practice

February 10, 2010

Having 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:

  1. People are often more afraid of the perceived problems than the practical realities of parallel development.
  2. People do not truly appreciate the problems and practical realities of version control and parallel development.
  3. 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.
  4. There is a quite substantial book that could be written on the subject.

Read the rest of this entry »

h1

Who’s afraid of the big bad merge?

February 1, 2010

A 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 »

h1

Common Interface

January 31, 2010

After much deliberation and soul searching I’ve finally decided it’s time to address one of my all time bugbears. I am going to develop a set of transferable libraries for analysing and operating a CMS. And because I am most familiar with Perl (and, as explained in my earlier post Glue Software, I find it the most useful language for my needs) I shall write them in that language.

As with most people who have worked long enough on the coalface of SCM I have a ragtag collection of routines, scripts and utilities already but now is the time to pull them all together, clean them up, give some thought to a coherent design and build a better mousetrap that I can use whenever I go to a new client.

This is not an effort to develop a be-all-and-end-all CM system, but more a matter of me realising that I develop the same sort of scripts time and again. So I would be better off developing a more robust architecture that will allow me to exploit report generators or integrity checkers written when using one tool when I go to a client who uses another tool but has the same problem to be solved.

A typical example of a script I have written several times is one to check the integrity of a build configuration. Answering questions such as, ‘does this build configuration contain all, and only, the completed change requests assigned to this release?’

It would also be nice to have a tool for federated reporting across tools. Often clients have several version control tools and it would be nice to have one reporting front-end that I could plug into their many VCSs and get information about them all.

There are, of course, many problems to overcome (not least all the different philosophies supported by these tools) but this is not a case of trying to solve all problems in one go, rather the idea is to write a facade that will allow me to access the implementation tools through a common interface. In this way, all I need do for each client is write a new facade that complies with my own interface definitions but interrogates their particular implementation. The hard parts of these scripts, the logic, will remain unchanged and useful in multiple applications, treating the tools as databases.

As with many efforts born of frustration, this one is not completely thought out yet (in fact some of the ideas are positively vague), so expect more to come on this side project…

h1

Glue Software

January 25, 2010

As someone who inevitably becomes involved in the technical implementation of configuration management systems (CMS) I am often called upon to create what I choose to call ‘glue software’. Glue software is not a full integration between two products (often there is simply no way to fully integrate products) but rather it is a more Heath Robinson collection of scripts, triggers and hooks used to provide some connection between applications that support the CMS.

There are a multitude of technologies that can be used to create glue software, including but by means limited to; SQL, various shell scripts, C, C++, C#, Java, PHP, Python, various web technologies (XSLT, ASP etc.) and so on. Over the years I have used all of these and more but by far and away my favourite glue software development language is PERL. And here’s why… Read the rest of this entry »

h1

Holographic Configuration Management

January 14, 2010

The advent of the ‘cloud’ and the idea of massively distributed systems (think grid computing and SaaS) is the latest technology swing with the potential to impact configuration management practice. I say ‘potential’ because a properly designed and implemented configuration management system will be able to copy without too much difficulty. The main impact will be procedural and technical, the underlying configuration management process will remain unchanged.

A properly designed CM system will be able to handle any IT system environment. Problems only occur when you are married to the idea that centralised control of CM data and centralised change control are necessary for CM, or that a specific development process is integral to CM for it to function correctly. Read the rest of this entry »

h1

The virtue of indolence

January 12, 2010

It has long appeared to me that people see virtue in making work. I see virtue in laziness. Or rather, I see virtue in eliminating work.

As a freelancers I see part if my role on an contract as eliminating as much of the purpose for my presence as possible. This means optimizing away my role, generally through process efficiency (ensuring there are no extraneous operations in the process), automating as much as possible, and ensuring that my role is not performing tasks that can be performed by others. Read the rest of this entry »