DevOps and You

What is DevOps?

It is a concept that seeks to remove the communication barriers between development, QA, and IT (operations).  When all teams are communicating openly and effectively, the following benefits may be achieved:

• shorter release cycle for new features
• lower percentage of bugs that make it to production
• better utilization of the organization's hardware and cloud resources

Is there a precedent for this concept?

In the 1990's, Toyota implemented a philosophy of "lean manufacturing" that reduced their production costs while simultaneously increasing their production line flexibility and their product quality.  This is the same goal of the DevOps concept.  Any software organization that has competitors (not all do) must constantly focus on staying competitive by reducing costs, increasing the product innovation, and reducing the relative percentage of bugs released into production.

What are specific issues that need to be addressed?

First I must point out that it is very difficult to change the behavior of groups of people when the behaviors have been entrenched for many years.  For example:

If you are a developer, have you ever been frustrated with QA because they never seem to find your bugs unless it is 5pm on that same night that you plan to see your four year old daughter's ballet recital?

Or, if you are in QA, have you ever been frustrated with development because they never seem to give you a build until it is 5pm on the same night that you plan to reconcile with your girlfriend/boyfriend at her/his special restaurant?

Better yet if you are a system administrator, have you ever been frustrated with everyone because no one tells you of a major release until 5pm on the same night that you plan to go night hang gliding with a bright flashlight?  (I ran out of ideas on that one...I hope you thought it was funny.)

The point is that most software development organizations are set up to keep the teams focused on their task at hand.  Often, there is not much inter-team communication.  Once the teams do communicate, it is often incidental or emergency event driven.  Therefore, the fundamental change required to begin thinking in terms of "lean" or DevOps is to open communication between teams.

The goal of opening up the communication is to allow team members from each team to understand the challenges faced by each team.  In other words, each team member should begin to understand that their team is only a part of the greater whole, the company/organization itself.

How can behavior be changed?

In order to bring about change in behavior within an organization, there must be a high ranking sponsor that can champion the change.  There must also be a technical leader that is viewed as objective among the teams.  This is often an architect, a release manager, or a technical director.  The technical leader would work with the teams to identify tools and procedures that facilitate communication between the teams and visibility within the teams.

Beyond leadership, what else can drive change to behavior?

Tools.  Tools act as the catalyst to change the behavior of the groups within the organization.  The tools chosen must be capable of showing measurable results.  For example:

• Continuous Integration
• TeamCity
• CruiseControl (Java, .NET, and Ruby versions)
• TFS Build Service
• Bamboo
• Jenkins (came from Hudson)
• Tinderbox
• (many, many more)
• Bug Tracking
• Jira
• MS Team Foundation Server
• Mantis
• (many, many more)
• Development Tools with Team Integration / Collaboration
• IntelliJIDEA & JetBrains in-general
• Visual Studio
• Eclipse
• Team Collaboration and Agile Tools
• Confluence
• VersionOne
• ALM on MS Team Foundation Server
• (many, many more)
• IT Orchestration Tools (manage physical, virtual, and cloud nodes)
• Puppet
• Chef
• Salt
• Ansible
• Network Administration Tools
• RANCID - compatible with Cisco, Juniper, J5, etc.
• Cacti - network graphing
• Windows Network Status Reporting
• (many, many more)

Conclusion

DevOps may not be new to you if your organization has already been communicating across teams effectively and releasing products continuously with fewer bugs.  However, there are still plenty of companies that have not had a need to focus on efficiency of product development.  So, if you are a developer, a tester, a system administrator, a support engineer, a release manager, an architect, a manager, a director, a product owner, a business analyst, a sales person, or an executive in a company that does not focus on DevOps by name or otherwise, then you need to consider it.  DevOps, the term, has been around since 2009 (as far as I know).  DevOps the practice has been around since much longer.  However, there are many tools that are now showing their value in the real world.  This means that your competitors may be slowly converting to the DevOps approach or converting all at once.

It is my opinion that DevOps is here to stay.  It is possible that the term may change over time, but the tools that facilitate the process are not going away.  Furthermore, the companies that choose to make use of these tools will continue to evolve over time.  Their competitors that do not follow the DevOps approach will likely not be able to keep up and potentially lose customers as a result.