Welcome to Bob Aiello's CM Best Practices Website!

Please register for our newsletter and event announcements!

Hi, this is the website to support my book on Configuration Management Best Practices. We also provide consulting services to help you implement all of the CM Best Practices described in our book. CM Best Practices Book

Writing any technology book is very challenging because the landscape changes even before the book is off the printer. This website will help elaborate on the key concepts in the book. I hope to hear from you soon!

You can also contact me directly to discuss how our consulting services can help you implement Configuration Management Best Practices or if you would like to join our network of tools and process agnostic CM gurus.

Writing for me is a team sport, so please link with me on linkedin and do drop me a line (again my email address is posted on linkedin) to let me know what you liked most about my book and where I can improve to help you successfully implement Configuration Management Best Practices!

I am glad to make arrangements to give you a signed copy from my own supply at a cost of $30 a book plus postage. I am also available for training and consulting services (more on that soon).

Please register for updates and access to future content.

Bob Aiello
http://www.linkedin.com/in/BobAiello

Title: Configuration Management Best Practices: Practical Methods that Work in the Real World
Publisher: Addison-Wesley Professional
Print ISBN-10: 0-321-68586-5
Print ISBN-13: 978-0-321-68586-5

Available now in print and ebook on InformIT:
http://www.informit.com/store/product.aspx?isbn=0321685865"

Shipping now from Amazon!
http://amzn.com/0321685865

As always, writing for me is a team sport so I am looking forward to your feedback. Please link with me onhttps://www.linkedin.com/in/BobAiello

CM Best Practices on Twitter
Our twitter accounts are https://www.twitter.com/cmbestpractices

My personal twitter https://www.twitter.com/bobaiello

Originally available in pre-published form on Safari Rough Cuts http://www.informit.com/store/product.aspx?isbn=9780321699992

Is DevOps Really New?

Written by Bob Aiello
Monday, 04 June 2012 18:17
DevOps is viewed by many as having started at the first DevOps Days Conference which was organized by Patrick Debois. DevOps is also regarded by many to be an outcome of Agile Systems Administration although much of the core DevOps concepts are not new by any means. DevOps highlights the essential partnership of Development and Operations and the synergy that comes from a cross-functional team that empowers both of these key players. Of course cross-functional teams are not new either. So I ask again, “is DevOps really new?” The concepts in DevOps have been around a long time. But what is new is the appropriate focus and communication of DevOps princples. DevOps is all about improved communication between Developement and Operations. It is no wonder that the DevOps movement has begun its journey by doing a great job of communicating some concepts that have been around (although relatively unnoticed) for quite some time. The rise of DevOps is, in many ways, a metaphor for what DevOps hopes to achieve in terms of improved communication between development and operations. DevOps is not alone in its emphasis on improved communication. The Agile and Lean practices have also largely repackaged some very important concepts that have been around a long time. I have written (in the CM Journal and my book on CM Best Practices) about my own experiences implementing these techniques over the course of many years. Lessons from EMS Recently, my youngest son - David - joined the family tradition as the third certified Emergency Medical Technician. There are very few things in life that I enjoyed more than my years as an EMT - helping to rescue, treat, and comfort people who had become injured. One thing that I emphasized to my son is that one must document everything that is done; this information is both crucial for those providing care when responsibility for the patient is transferred to the receiving medical facility and also serves as a record that proper teachment was indeed provided. In EMT speak, unless you wrote it on the Patient Care Report (PCR), then you didn't give the patient oxygen (bad move when it is needed). Lesson Learned The DevOps, Agile and Lean camps have done a great job of communicating essential IT wisdom that has been around a long time and the technology community is better served because of their efforts to highlight these principles! x
Last Updated on Wednesday, 15 August 2012 06:22

Git Branching

Written by Bob Aiello
Wednesday, 30 May 2012 20:57
Variant Management is usually handled by branching the code at a specific point in time. Some folks use branches to plan releases or track features. We will show examples of these approaches in future articles. In this article, we address the most essential branching pattern which is branching from a known baseline (as represented by a tag). For this example, I created a new git repository and simply added one readme file containing a date and time stamp. I tagged the repository at several points to make it easier to understand the example. [bob@myserver ~]$ mkdir gitexample [bob@myserver ~]$ cd gitexample [bob@myserver gitexample]$ git init Initialized empty Git repository in /home/bob/gitexample/.git/ [bob@myserver gitexample]$ date > readme.txt [bob@myserver gitexample]$ git add readme.txt [bob@myserver gitexample]$ git commit -a -m'first commit' Created initial commit de0d064: first commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 readme.txt [bob@myserver gitexample]$ git tag v1.0 [bob@myserver gitexample]$ git show v1.0 commit de0d0643cf32a032bb31cd9791ec758fb7d03348 Author: Bob Aiello < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > Date: Wed May 30 17:07:23 2012 -0700 first commit diff --git a/readme.txt b/readme.txt new file mode 100644 index 0000000..184f470 --- /dev/null +++ b/readme.txt @@ -0,0 +1 @@ +1. Wed May 30 17:06:55 MST 2012 At this point I have one readme file with a single date stamp that has been labeled v1.0. Next I will add another date stamp, commit the change and then baseline again using a tag called v2.0. [bob@myserver gitexample]$ date >> readme.txt [bob@myserver gitexample]$ git commit -a -m'second time' Created commit 907832f: second time 1 files changed, 1 insertions(+), 0 deletions(-) [bob@myserver gitexample]$ git tag v2.0 Next we examine (using the git show command) the two tags that were just created – v1.0 and v2.0. Note the cryptographic hash on the commit as shown below. [bob@myserver gitexample]$ git show v1.0 commit de0d0643cf32a032bb31cd9791ec758fb7d03348 Author: Bob Aiello < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > Date: Wed May 30 17:07:23 2012 -0700 first commit diff --git a/readme.txt b/readme.txt new file mode 100644 index 0000000..184f470 --- /dev/null +++ b/readme.txt @@ -0,0 +1 @@ +1. Wed May 30 17:06:55 MST 2012 [bob@myserver gitexample]$ git show v2.0 commit 907832f7650b5c504ec7c41d3d418f25d27a9e2c Author: Bob Aiello < This e-mail address is being protected from spambots. You need JavaScript enabled to view it > Date: Wed May 30 17:09:05 2012 -0700 second time diff --git a/readme.txt b/readme.txt index 184f470..b861d3f 100644 --- a/readme.txt +++ b/readme.txt @@ -1 +1,2 @@ 1. Wed May 30 17:06:55 MST 2012 +2. Wed May 30 17:08:40 MST 2012 The branch can be created using the hash associated with v1.0. I verify that the readme.txt file has two date stamps as expected. Then I checkout the branch created based upon the first baseline and verify that the readme file has only one date stamp as expected. We have effectively gotten into our version control time machine and created a branch for our development using the original baseline. This is exactly what you need to do when you are creating a bugfix branch. [bob@myserver gitexample]$ git branch br1.0 de0d0643cf32a032bb31cd9791ec758fb7d03348 [bob@myserver gitexample]$ cat readme.txt Wed May 30 17:06:55 MST 2012 Wed May 30 17:08:40 MST 2012 [bob@myserver gitexample]$ git checkout br1.0 Switched to branch "br1.0" [bob@myserver gitexample]$ cat readme.txt Wed May 30 17:06:55 MST 2012 Using the cryptographic hash as the starting point helps me to really understand how git works, but it's pretty ugly. Let's try creating branches based upon the tag names which is much easier to read. In the following example, we create branch br-v1.0 based upon tag v1.0. We then checkout the branch that we just created and verify that we only see one datestamp. [bob@myserver gitexample]$ cat readme.txt Wed May 30 17:06:55 MST 2012 Wed May 30 17:08:40 MST 2012 [bob@myserver gitexample]$ git branch br-v1.0 v1.0 [bob@myserver gitexample]$ git checkout br-v1.0 Switched to branch "br-v1.0" [bob@myserver gitexample]$ ls -lt total 4 -rw-rw-r-- 1 bob bob 32 May 30 18:09 readme.txt [bob@myserver gitexample]$ cat readme.txt 1. Wed May 30 17:06:55 MST 2012 Next we will create a new branch based upon the v3.0 tag. This time checking out the new branch that we just created shows the readme file with the second datestamp. [bob@myserver gitexample]$ git branch br-v3.0 v3.0 [bob@myserver gitexample]$ git checkout br-v3.0 Switched to branch "br-v3.0" [bob@myserver gitexample]$ ls -lt total 4 -rw-rw-r-- 1 bob bob 64 May 30 18:11 readme.txt [bob@myserver gitexample]$ cat readme.txt 1. Wed May 30 17:06:55 MST 2012 2. Wed May 30 17:08:40 MST 2012 Git has some pretty cool features and effective use of tags and branches are essential for managing baselines and code variants. Please drop me a line and tell me about your own experiences coming up to speed with Git!
Last Updated on Monday, 04 June 2012 17:35

Agile ALM

Bob Aiello With the new year upon us, it is good to reflect upon our accomplishments, mistakes made and, of course, the obstacles that are ahead. This is a very challenging time for technology professionals. There are many factors impacting success along with demands for talent, skills and commitment to "raising the bar" to achieve our desired goals. Developing software and systems has become a remarkably complex task with many factors impacting the success of the development effort. {quote}Teams may be located in one specific “war” room or distributed across the globe, working at different hours of the day with varying languages, cultures and expectations for how they will operate on a daily basis.{/quote} The competition for specialized technical resources motivates many organizations to allow flexible work arrangements including telecommuting along with choosing office locations convenient to attract local candidates. Technology professionals choose between the demands of high paying (and often stressful) opportunities and trying to maintain a work-life balance. All the while learning new development frameworks and adapting legacy systems to meet the need for continued growth and flexibility. The internet has clearly become the backbone of commerce and companies are expected to continuously align themselves with growing web capabilities in order to achieve and maintain success.

Dealing Successfully with Complexity

It is clear that successful organizations need to support complex technologies, most often with a significant web presence. Even companies going out of business are expected to have a functioning web presence capable of handling the peek transaction requirements of customers and other users. In practice, these complex development efforts necessitate effective processes and methodologies to meet the demands of today and those that will surface in the future.

Agile CM and ALM

Agile Configuration Management (CM) and, by extension, Agile Application Lifecycle Management (ALM) have become two of the most popular software development methodologies in use today. Agile has resulted in indisputable successes boasting improved productivity and quality. My career has always involved 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 that succeeded 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 the 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 Management

Application Lifecycle Management (ALM) developed from the early days of process improvement 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 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 world

Agile 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 the year and beyond.

Your Turn

There is more to the story of course and please drop me a line and let me know what you think of Agile ALM and how it may or may not impact your technology development efforts!

Tools for ALM

Written by Bob Aiello
Wednesday, 30 May 2012 16:47
Tools for Application Lifecycle Management by Bob Aiello I 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 Tools As 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 ALM Agile 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 that succeeded 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 Management Application 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 world Agile 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. Conclusion Attending 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.
Last Updated on Monday, 04 June 2012 06:03