Archive for the ‘Plain Old Blog’ Category

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

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 ?

h1

Labels versus Baselines

January 7, 2010

A common question from new Configuration Managers is, “What is the difference between a label and a baseline”.

A label is exactly what it sounds like, a name assigned to one or more things (whatever they are). Generally no further qualification is needed.

A baseline, in configuration management circles, has much more significance.

A baseline is an immutable set of items, including all the information that specifies those items and records of how those items where derived. Baselines are subject to audit to confirm their integrity. The precise nature of these audits varies according to lifecycle phase and the environment (safety critical, commercial, defence and so on). Apart from situation specific requirements baseline audits typically aim to establish, as a minimum:

  • The baseline contains all relevant items.
  • The baseline is correctly identified.
  • The records (change records and so on) associated with the baseline are secure, accurate and reflect the true nature of the baseline.
  • The baseline is secure; that is, the baseline items are held in a fashion that ensures their availability.
  • The baseline has been established through the approved process. For example, that all appropriate development, change and testing has be performed according to the established development methodology.