Dienstag, 29. April 2008
Missing artefacts in Configuration Management
If you want to apply configuration management, you should put everything under configuration control, what is responsible for the behaviour for the application. The only exception is system configuration data, which you have to change during the staging. Typical examples are hostnames, tcp/ip-addresses, user accounts and passwords.

All other files should be in configuration management and picked up during the build.

So let’s define a second litmus test:

For every application which you own, build and deploy it from the sources which you have got from the configuration systems. The deployment system is the naked target platform, e.g. Some Unix Servers, with a clean new installation of your application server, an empty and clean Oracle database, with the correct set of patchlevels, …

If you need to copy files from somewhere else.
If you have to export some files from some system, and then “modify” it and deploy it.
If you have to export/create/generate one or more files from some very fancy tool, with a very graphical GUI, whose import is not completely under configuration control. Succeeded:
If all you need to deploy the application with a standard process is in the configuration management system. The only exceptions are some updates of configurations settings which do only depend on the environment, (e.g. user accounts passwords, hostnames, etc.)

Most companies (seven out of eight on my personal experience) fail with this more advanced but still “simple” test.

But why and where do they fail? I recognized following major reasons why and where they fail:

  • They have forgotten to put some important artefacts under configuration mangement, e.g. Database schema scripts or application server configuration and customisations.
  • They use something like a workflow engine, a process engine, a business rule engine or any other nice and fancy tool, which is used by “business analysts” to design a workflow or orchestrate some business process or define some business rules.
In the first case, the solution is quite easy and straight forward. Just put the missing elements under configuration management.

The second case is much more critical, because it is based on the WRONG assumption:

Designing a workflow or orchestrating some business processes or defining some business rules is not developing.

The truth is: The business analyst is developing. Period. He is just developing in a kind of DSL (Domain Specific Language), but he is developing. If he makes a mistake, the system has a bug. The process, workflow or business rule will fail or produce wrong results similarly to other buggy development artefacts.
So put also these artefacts under configuration management.

... comment