Friday, November 11, 2011

Veterans’ Day

Every year I like to thank those Veterans close to my family and me:

Retired:

  • Roland F. Chapman (Grandfather -b1910-d1987 - Navy)
  • Robert D. Boss (Dad - Navy)
  • Michael J. Boss-Hill (Brother – Air Force)
  • Stephan J. Hill (Step Dad – Navy)
  • Fredrick R. Chapman (Uncle – Army)
  • Mark Hanson (Uncle – Navy)
  • David Bishop (Navy)
  • Charles W. Hobbs (Navy)
  • Dawn Meiers (Navy)
  • Chuck Norris (Navy)
  • Arthur Pignataro (b1944-d2011 - Army)
  • Dodd Schock (Navy)
  • Ronald Steele (Navy)
  • Rick Kolde (Navy)

Active Duty:

  • Kevin P. Boss-Hill (Brother – Marines)

There are many more in all of our lives.  Thanks to you all.

Till next time…

Monday, November 07, 2011

Software Environments: Separation and Configuration is Key

I just left a meeting with several folks from the server group, the web services group, and my applications group.  The discussion was around environments and promotion of software through these environments. Let me tell you, there are some very different ideas out there regarding this process.

I thought I would let you know how I prefer to make this work so that there is the best opportunity for a successful installation. Now these concepts are not specific to internal software development where the customer is part of the same organization as the group developing the software. These concepts are the same for shrink wrap or cloud based software.  I have worked with all of these types of software development projects and have been successful utilizing these concepts.

The first, and arguably one of the hardest to implement, is the concept of a separation of environments. The separation of environments from step to step should encompass all pieces of a software system wherever possible. This means that each environment should have, where applicable, a web services server, an application server, a database instance (server if possible) to name a few. 

At a minimum a team should have three such environments; a development environment, a test environment, and a production environment. Each containing a distinct and atomic system that requires gates to be passed in order to achieve entry.

These gates should include automated unit tests and code analysis. The code deployed in each environment should have been proven in the previous environment. The automated code that does the actual deployment to each environment should be exactly the same in each environment so you are always executing the same thing from environment to environment and not creating unnecessary variables.  This allows you to have the experience of many deployments prior to the one crucial deployment to production, thus mitigating and alleviating most risks of deployment.

One of the single most important aspects of achieving separation of environments is Configuration Management. Configuration Management is the management of all pieces of a software product’s lifecycle from initial coding through deployment. Configuration Management as a discipline in software development is getting more and more respect these days, for which I am very happy. This is a very challenging aspect to any software development project.  A properly maintained and automated configuration management system is a must for any organization that puts any product into production ands wants to do it as efficiently as possible.

It is the details of each system where a configuration management engineer earns his money. Each will be different based on the product, but the concepts are the same.  One of my favorite books Software Configuration Management Patterns deals with some of these concepts and how source control management is an integral part of the process.

No matter what system you are working on, try to keep your environments separated and remember: automate, automate, automate.

Till next time…