Insights >Blog

Is Software Configuration Management being applied nowadays?

Miguel D'Amore

June 23rd, 2013

Software Configuration Management (CM) is an engineering and management discipline that focuses on the management of change. The change management is performed against what it is called configuration items (code, tools, documents, designs, products, and any artifact you want to manage). The primary goal is keeping the configuration items´ integrity and quality; in order to achieve that goal configuration management proposes processes to identify and control changes, create baselines and audit the configuration items.

The CM core areas are categorized as:

  • Source code management
  • Build engineering
  • Environment configurations
  • Change control
  • Release engineering
  • Deployment

The CM basic practices are divided in:

  • Identify
    • Detect
    • Name
    • Acquire
    • Baseline
    • Control
      • Version Control
      • Change Control
      • Build Management
      • Release engineering
      • Audit
        • Analyze baselines and processes
        • Non-compliance management
        • Report
          • Document and notify changes
          • Quality and productivity metrics
          • Audit results
          • Version history of configuration items

Configuration Management has been around since the 1950s, primarily used by the United States Department of Defense to manage changes to hardware and later to software. Over all these years many books were written about CM and many of them treated CM as a core management methodology for software projects. With the advent of RUP and later Agile methodologies, CM started losing space as an important practice with its own identity, in the former because of the exhaustive and detailed processes and artifacts prescription and in the latter because of the opposite reason.

Today CM is in force as much as it was in the very beginning; indeed I can’t imagine a successful software project without CM. Many organizations have implemented CM through CMMI, ISO and ITIL among other models and frameworks where CM practices are included. Almost all software projects nowadays implement CM practices even without knowing the origin of the practices. Tools like code versioning repositories (CVS, SVN, GIT), issue trackers (Redmine, Jira, Track) and continuous integration servers (Team City, Jenkins, Cruise Control) enforce and facilitate CM practices within the software projects.

Is there more value to CM than that delivered through models, frameworks and tools that include some of its practices?

Well certainly there is. Mature software companies have extensive categorized lists of CM related practices they follow in every project. These good practices are not agile, nor any other methodology, disruptive, so they can be incorporated to the company’s and software projects’ quality standards.

Examples of CM related good practices:

  • Source code management
    • Code Style Standard
    • Does your methodology guarantee that source code can never be lost?
    • Is your source code safely locked down?
    • Source code iteration based baseline
    • After establishing an iteration code version base line, no more code uploads associated to the ending iteration should be present in the same branch/tag
    • Code variants are properly branched
    • Is each code upload related only to a single issue?
    • Each code upload must be related to an issue
    • Code lines and Branching/Tagging definition
  • Build engineering
    • Reliably compile, link, and package code components
    • The source code and compile dependencies can be easily determined
    • Continuous Integration: Build anomalies are identified and managed in an acceptable way
    • The cause of broken builds is quickly and easily identified and fixed
  • Environment configuration
    • Environments Definition (Dev, QA, Integration, Prod)
    • Environment configurations should be changed in a controlled and predictable way
    • Code should be rebuilt and redeployed after any environment change
    • Environment Specification (Environment configurations should be documented and understood by all parties)
  • Change Control
    • Any change in the code should provide an Impact Analysis
    • Requirement specification process. Goal to requirement transformation process
    • Requirement approval workflow
    • Requirements prioritization process
    • Gatekeeping: Function that prevents unauthorized releases from being promoted into another environment.
    • Pre change control: Necessary tests/acceptance criteria to allow the environment promotion.
  • Release Management
    • Releases should be readily identifiable with an immutable version ID.
    • Each version should have a change log comparing the last version with the present one
    • Releases should be packaged with all the dependencies included.
    • Release packaging should be automated and designed to avoid human error.
    • There should be a mechanism to conduct an audit of a release package to verify all of its configuration items.
    • The contents of a release should be well understood, including the tracking of requirements.
    • Release management should be a source of information on the status of all releases, ideally though a release management dashboard: To be implemented, In Progress, Release ready, Released
    • Product Versioning Methodology: Product version patching, Product version approval, Product version delivery
    • Database Structure Versioning (From scratch and update scripts)
    • Database test data set Versioning
  • Deployment
    • Product version promotion/staging into environments process.
    • Tests should be performed to ensure a properly done deploy
    • There should be a well-established procedure for checking the effectively deployed versions of a release in every environment
    • Deployments communication
    • Deployment process per environment definition
  • CM Support Tools Configuration
    • Source code versioning repository integration with the issue tracker
    • Do you distinguish the following concepts/items in your issue tracker?
      • Backlogs
      • Goal / Backlog Item / Epic
      • Functional requirement
      • Nonfunctional requirement
      • Cross requirement/scenarios acceptance criteria (issue type or flag)
      • Task / Requirement implementation task
      • Impact analysis (at least post change analysis).
      • Product Enhancement proposal
      • Impediment
      • Process Enhancement proposal
      • Bug / Defect
      • Testing strategy used when the bug was found
      • Source of error: (Requirements, Design, Coding, Testing Environment, Wrong Testing, Other, etc.)
      • Testing sessions count
      • Issues status / Issue status workflow
      • Author
      • Change history (A test case change log should exist where the date, changes author and the changes made are logged)
  • Traceability
    • Source code versioning repository – Issue tracker
    • Source code versioning repository – Product Version
    • Source code versioning repository – Deployed system
    • Issue tracker – Sprint
    • Issue tracker – Product Version
    • Regression failed tests – Issue Tracker Bugs
    • Regression test report – Product Version
    • Test case catalog – Product Version
    • Impact analysis area – Test case
    • Product Version – Environment deploy
    • Goal – Requirements
    • Requirements implementation – Sprints
    • Implementation task – Requirement
  • And more


These sets of good practices are accumulated and evolved by software organizations as learning and improvement process, typically it takes year to have a solid set of processes, practices, templates, and checklists among others.

In my opinion a successful software company combines solid technical skills, is able to scale/adapt agile frameworks to what the projects need, have strong CM standards, robust software quality management (including quality control and quality assurance) and the most important attribute is that the company should be capable to adapt their service system according to each project/client and still be able to manage that service system as a configuration item (using baselines, change control, etc.).

Probably you won’t find complete CM implementations as a standalone and main framework implementation; you will find CM practices applied because of frameworks and models implementations like CMMI, ISO, ITIL or through default support tools settings. It’s a good idea anyway to evaluate your work from the CM perspective and see if you can adopt more practices or improve the ones you already have only in order to have solid organizational CM standards.

CM is still one of the cornerstones of software development projects.

If you are looking for a software partner or software outsourcing services take in consideration what we discussed here, a mature service provider company will improve your processes/practices and will have a minor project ramp up time.


Related posts

See also


Software development

Software testing

Consultancy & innovation

User experience



Media & entertainment


All industries






Why Belatrix?

International presence

Nearshore advantages

Project governance

Agile expertise

Flexible engagement models

Our talent development