Overview of DevOps: notes from IBM Innovate 2013

DevOps was by far the main concept that IBM was pushing at the Innovate Technical Summit; nearly every session I attended had some portion dedicated to how they fit into the IBM DevOps infrastructure/methodology.

In general, DevOps refers to best practices a company can use to reduce friction when handing off software between development and operations.  This reduces the time it takes a company to deliver something of value to their customers. Reducing friction refers to changing the culture of an organization to eliminate any technical or procedural barriers that hinders the ability to deliver software in a predictable way with the minimal amount of manual work.

By adopting some common-sense practices, a company can become more agile, deliver products to their customers sooner, and increase their chance for success. Some of the DevOps best practices highlighted were:

• Ensuring development and production environments are as similar as possible
• Automating as much as possible – tests, system setup, deployment
• Flexibility of processes – IT and project management should be as agile and flexible as the development teams
• Fostering an environment of open communication between the groups tasked with developing and deploying software – this should be done through as many channels as needed to make communication between these groups easier.

The final key concept of DevOps is the amplification of feedback loops between stakeholders; it is critical to have the ability to observe how changes impact a system, and apply this data to the next set of changes.  To enable this, continual monitoring and observation about critical system metrics must be collected and used.

IBM refers to this philosophy as the DevOps Lifecycle. They have taken steps to evolve their tool chain to support this in any organization.

Lessons Learned:

• Configuration and Change Management: DevOps encourages the versioning of every asset needed to build a product. This is not just source; this is all libraries, environment scripts, virtual systems. Without an established source of truth, you will not be able to continuously deliver. Leverage Automation: This refers to a concept called ‘Change Management,’ where you need to have an idea of how any change effects the system as a whole. The goal of this is to automate the complete test and delivery process of the system; eliminating all manual changes will allow you to synchronize all areas during a ‘deployment’. This will encourage developers to make many small incremental changes to a system, which reduces integration risk.
• Leverage Virtualization: most of the methods in which IBM recommended implementing DevOps at a company involved the use of virtualization. Virtualization of systems and network topologies allows the organization to consider the environment needed to build and deploy a project as ‘code’, which is also versionable – ‘infrastructure as code’.
• Continuous Delivery: In order to implement Continuous Delivery, an organization must make investments in Continuous Testing, Continuous Integration, and Continuous Monitoring.  In order to implement continuous testing and integration, a program will need to make improvements to their development infrastructure such as build automation and virtualization. When considered in this way, a program could be ready to make the transition to Continuous Delivery.  

Rational tools such as Team Concert, Rhapsody, etc. are very mature and can support an agile DevOps culture. IBM development teams are using their own tools to enable their internal DevOps efforts.