Configuration Management 100

As the subject gets more popular, and my commercial responsibilities are urging to get the best out of it, I am starting to write a series of blogs for Configuration Management[CM], often interchangeable with Change Management

In his book “Adapting Configuration Management for Agile Teams“, Mario E. Moreira explains it as

the discipline of making changes in a planned and systematic fashion. The ultimate task is the integrity of our artifacts and activities. CM is about identification, organization and control of software to maximize productivity by minimizing mistakes.

According to IEEE , the phases for CM are:

1. Configuration Identification:
Detect Configuration Items (CIs), Name them, Acquire them,  and create a baseline
CIs can any product deliverables, corresponding plans, requirements, specifications, design, source code, executable, tools, system information.

2. Configuration Control:

a. Version Controlling: As repository starts its life, it will be changed. For each set of changes, we should know exact version of the source code. Version Controlling Systems give  a unique check-in number.

b.Change Controlling: Each request/change has a unique identifier. Through a good Incident Management process [ITIL does help a lot], it is assigned to relevant people, with detailed information about the version of the product referred, its priority, and if it is a subset of another change, the parent change, authorized by a controller.

The good thing about TFS is that Version Controlling and Change Management are nicely coupled, so for each check-in, you (may) have to tell the number of the change request[You may want to read negative parts]. This increases the traceability of the source code.

Build Management:
When a set of requirements have been fulfilled, we do build the code, and give a number for the version.
The build process includes
– Branching Strategy: Snuffybear has a good article about the strategies:

Model-1 Small Team Model using Emergency Fix Branches
This strategy is for a team of 5 or less, working from the same repository, for the same project, no need for differentiation of the source code.

Model-2 Medium Team Model using a separate developer and release branch
This is for a development team, doing development and bug fixing with different teams. A branch category is for development, and a branch category is for bug-fixing.

Model-3 Large Team Model using parallel development streams
This is for teams heavily working on new features/projects in addition to the code base.
– Continuous Integration process, which is an immediate response of the health check of the integrity of the code. Any Continuous Integration tool can be configured to do the checks for every/after x number of times of check-in/merge.

c. Release Engineering : The project is tested and we are happy to go live, then the version of the release is published, and LIVE environment gets ready for deployment. Deployment process will be another subject for my blog.

3. Configuration Status Control/Accounting:
Collect the data
Record data in a  measurable, meaningful, repeatable way.

4. Configuration Auditing:
Analyse the baseline and processes.

Any comments on the tools/processes you are (un)happy about?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s