We provide customized training onsite and remote (via webex) to enable your to team to fully understand and implement configuration management best practices including  DevOps.CM Best Practices book



Based upon industry standards and frameworks this course introduces the technology professional to all of the principles,concepts and hands-on best practices necessary to establish comprehensive configuration and release management functions. This class covers essential CM concepts as they are practiced in product companies and IT organizations.

Contact us
for information on customized Configuration Management training!!!

Configuration Management Best Practices Training Program


Based upon industry standards and frameworks this course introduces the technology professional to all of the principles, concepts and hands-on best practices necessary to establish a comprehensive configuration and release management functions. Discussing both CM as it is practiced in product companies and IT organizations, Bob Aiello and Leslie Sachs provide expert guidance on establishing configuration management best practices.


  1. Configuration Management Concepts
    * Configuration Identification
    * Status Accounting
    * Change Control
    * Configuration Auditing (physical and functional)
  2. Source Code Management
    * Baselines
    * Sandboxes and Workspaces
    * Variant Management
    * Handling bugfixes
    * Streams
    * Merging
    * Changesets
  3. Build Engineering
    * Versions IDs and branding executables
    * Automating the build
    * Build tools to choose from including Ant, Maven, Make and MS  Build
    * Role of the Build Engineer
    * Continuous Integration
  4. Environment Configuration
    * Supporting Code Promotion
    * Implementing Tokens
    * Practical use of CMDBs
    * Managing Environments
  5. Change Control
    * Types of Change Control
    * Rightsizing the Change Control Process
    * The 29 minute Change Control Meeting
    * Driving the Process Through Change Control
  6. Release Management
    * Packaging the release
    * Ergonomics of Release Management
    * RM as coordination
    * Driving the RM Process
  7. Deployment
    * Staging the release
    * Deployment frameworks
    * Traceability
  8. Architecting Your Application for CM
    * CM Driven Development
    * How CM Facilitates Good Development
    * Build Engineering as a Service
  9. Hardware CM
    * Managing Hardware Configuration Items
    * Hybrid hardware/software CM
  10. Process Engineering (Rightsizing)
    * Agile/Waterfall
    * Hybrid Approaches
    * Agile Process Maturity
  11. Establishing IT Governance
    * Establishing IT Governance
    * Transparency
    * Improving the Process
  12. What you need to know about Compliance
    * Common Compliance Requirements
    * Establishing IT Controls
  13. Standards and Frameworks
    * What you need to know about standards and frameworks
  14. CM Assessments
    * Evaluating the Existing CM Practices
    * Documenting “As-Is” and “To-Be”
    * Writing your CM Best Practices Implementation Plan


Our training programs are customized for your needs!





Related Articles:

More articles by this author

Tools for Application Lifecycle Managementby Bob AielloI always enjoy attending conferences and learning about the best practices promoted by my colleagues employing the latest products and tools. In my opinion, many vendors are doing an excellent job of raising the bar for tools that support Application Lifecycle Management (ALM). The leading tools today not only come with great features, but also often include process models heavily influenced by the experiences of many tech savvy (and demanding) customers. You need to understand how to benefit from today's leading tools that have matured in the competitive space of application lifecycle management (ALM).Process Over ToolsAs an (MA-level) industrial psychologist, working in software engineering, I have always focused on software process and process improvement. The mantra that I learned early on was that process was a lot more important than tools. ALM actually changes the game though. In the ALM space, tools can make or break the entire software development effort. Configuration Management is one of the most important areas where tools are just as important as the process[1]. Whether you are using Agile, Waterfall or another methodology, tools may very well be the key to your success. This is especially true when implementing CM for Agile development.Agile CM and ALMAgile Configuration Management (CM) and, by extension, Agile Application Lifecycle Management (ALM) are extremely effective. Agile has resulted in indisputable successes boasting improved productivity and quality. My career has focused on Software Process Improvement with a particular focus on Configuration Management for over twenty five years. As a practitioner, I am completely tools and process agnostic. I have seen projects that successfully employed Agile methods and other efforts that thrived on an Iterative Waterfall approach. Still most organizations need a reliable and repeatable way to manage work, allowing full traceability and clear, complete communication. Years ago, we looked to the Software Development Lifecycle (SDLC) to guide us, although process documentation often sat on the shelf along with the outdated requirements specification from the latest software or systems development effort. Many companies struggled with improving programmer productivity and some tried to use the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM). These efforts often had limited success, and even those thatsucceeded had limited return on their investment due to the excessive cost and effort involved. The SEI chartered a series of Software Process Improvement Networks (SPINs) throughout the United States which provided speakers and opportunities to meet with other professionals involved with software process improvement. I had the pleasure of serving for many years on the steering committee of one of the SPINs located in a major city. Today, most of the SPIN presentations have a focus on Agile practices and most of the attendees are interested in establishing SCRUMs, iterative development and Agile testing. Agile has certainly had a major impact on software process improvement. Application Lifecycle Management (ALM) has also had a major impact upon how software development is conducted, particularly in large scale distributed environments.Application Lifecycle ManagementApplication Lifecycle Management (ALM) developed from the early days of software development lifecycle (SDLC) to provide a comprehensive software development methodology that provides guidance from requirements gathering to design, development all the way through to application deployment. In practice, ALM takes a wide focus with many organizations establishing an ALM to manage their entire software and systems delivery effort. Some organizations successfully implement ALM in a way that would not be considered Agile using a Waterfall model that has a heavy focus on completing the tasks in each phase before moving on to the next. Configuration Management, consisting of source code management, build engineering, environment configuration, change control, release management and deployment have been a key focus of ALM for some time now. Another key focus has been applying Agile principles to support and improve Configuration Management functions.Agile CM in an ALM worldAgile Configuration Management provides support for effective iterative development including fast builds, continuous integration, and test driven development (TDD) that is essential for successful Agile development. In a demanding fast-paced software or systems development effort, Agile CM can make the difference between success and failure. Establishing effective Agile CM and ALM practices can help you achieve success in your current (and future) projects.ConclusionAttending conferences and networking with colleagues is a fantastic way to learn about industry best practices. Vendors have done an amazing job of integrating toolsets to support the entire application lifecycle. You need to enjoy the benefits of these integrated approaches to ALM. Make sure you drop me a line and share your best practices too![1] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010.
When you deploy a release you need to verify that the correct files were copied to the target directory as expected (often called a configuration audit). You also want to verify that unauthorized changes have not occurred (e.g. tampering with a release). I have used intrusion detection tools to protect my production baseline and verify that unauthorized changes did not occur. Another approach is to write cryptographic hashes on each configuration item and then check them to verify that the file has not been changed. This is known as creating an application baseline and here is how this works. Step 1 is to create a file with a list of files to be verified. (We use the find command as shown). For our example, there are only three files as shown. find /home/bob/public_html –type f > files.inp   cat myfoo.txt 1 | 800e4d29a80abfd0aebbc0fa400e1b0d84dc006e | /home/bob/public_html/robots.txt 2 | 727d15736fdc1bef578611063cd731e774138dbb | /home/bob/public_html/readme.txt 3 | 8633ac8ccfb376c592caf8541d3ebc4c45533648 | /home/bob/public_html/index.php   Next we run the script which calculates the SHA1 hash for the readme file listed above. ./mybaseline.rb 1 | 3f290e089b0aeb08e7e2dd5e3ea6e27947b61b15 | /bob/ruby/readme.txt We will use the date command to make an “unauthorized” change to the readme.txt file and rerun the script to calculate the SHA1 hash. You now see that the hashes do not match which indicates that the readme file was changed. [bob@myserver ruby]# date >> readme.txt [bob@myserver ruby]# ./mybaseline.rb 1 | e04461d3822a9c69af132844cd59496ca17c2227 | /bob/ruby/readme.txt     Here is the code that reads each file and calculates the SHA1 hash. [bob@myserver ruby]# cat ./mybaseline.rb #!/usr/bin/ruby #mybaseline.rb require 'digest/md5' require 'digest/sha1' counter = 1 file ="files.inp", "r") while (myfilename = file.gets) sha1_digest1 = Dir.chdir(File.dirname(myfilename)) myfilename = myfilename.chomp! myfile =, 'r') myfile.each_line do |line| sha1_digest1 << line end puts "# | # |#" myfile.close counter = counter + 1 end   The program begins by including the md5 and sha1 digests (allowing you to calculate either hash). We read through the list of files in files.inp (created by the find command as mentioned above). Then we read each file and calculate the SHA1 hash and finally print the filename, path and the SHA1 hash.   Part 2 of this article is Verifying Baselines with Ruby!