May 25th, 2016
DevOps is the end to end collaboration, performance measurement, and process automation flow. It enhances the software development lifecycle between development and operations teams; getting from business idea to measureable customer action with speed and agility in minutes and not months. It allows the team to be agile but at the same time mitigating risk. How can this be done? This concept is based upon six principles.
Principle #1: Culture
This, 
by far, is the most important principle of the six, and it sits at the top of the list for a reason. Each organization has a different culture regarding how Dev. and Ops. are viewed within the organization. With many organizations, these two teams appear to be opposing forces. In DevOps, it is critical they work together, or as one. Their goal is to deliver successful results for the business for whom they work. This means coming together to develop a single methodology using people, process and technology. They must work together in harmony and foster an understanding of the challenges faced by each team. Adopting a holistic approach to delivery of the end-product or service is key. Removing the silos and building trust between the teams is essential in order for DevOps to be successful in your organization. The takeaway here is that everyone is working for the betterment of the company. Experimentation and change is NOT a bad thing.
Principle #2: Agile
Agile is the alternative to traditional project management (Waterfall), where emphasis is placed on empowering people to collaborate and make team decisions while undergoing continuous planning, testing, and integration. It was traditionally used in development environments to deliver applications much more quickly. However, the problem here was that developers would release software updates so frequently that it would make Operations’ jobs extremely difficult to maintain stability across the environment as all of these frequent changes were introduced. To address this problem, DevOps takes this concept and applies it to the Development and Operations environments by encouraging both teams to work together, collaborate, and exchange information while working across multiple identical and stable environments. It encourages change, experimentation, and continuous improvement throughout the entire service lifecycle. The benefit of this is the overall process of developing and delivering applications and services is faster when the two teams are working together as one.
Principle #3: Parity
When you have multiple environments at work you are bound to hear someone say, “Well, it worked in my environment.” Parity deals with the issue of disparity of equipment used by each set of users across multiple environments. Standardized interchangeable configurations of infrastructure components enable a more reliable system for application deployment, resulting in more predictable results. This enables a diverse group of participants to exercise an application while having the assurance that their results will be the same as the other participants. If all of the equipment is configured the same, the application will perform in the same manner. This is extremely important for those who are developing the application, testing the application and operating the application. This grants the confidence that the results seen in development are the results that will be seen in production. It also grants the assumption that if there is a failure in production then that failure will be reproducible in the test environment.
Principle #4: Automation
This principle is the most discernable because the tools become so ingrained in the process used by companies that have embraced DevOps. There is a guiding vision that says automate every process that is being performed manually. The benefit is that you will have a more repeatable process because human error has been eliminated from the process. Automation is typically faster than performing these tasks manually. So automation speeds up these processes and enables applications to be delivered to users faster. However, there are two guidelines here to remember:
- 1. Don’t automate what you don’t understand
- 2. Don’t automate what you can’t validate
Automation is a principle that guides the approach to implementing DevOps.
Principle #5: Measurement
This principle drives the collection of as many measurements as possible so they can be used in principle #6- Improvement. Once these are collected, DevOps embraces using these metrics to improve everything. Share, expose and communication these measurements to everyone. The reason to measure is not only to improve but also to communicate. Communication is part of collaboration. You are not only communicating to stakeholders and managers; you are also communicating with the rest of the team.
Principle #6: Improvement
In order to improve, you need to know and understand some baseline metrics of where you are today. Ask yourself, “How do we know we are improving if we have never measured this before?” Taking the measurements from Principle #5, communicate those to your stakeholders, managers and team members. Collaborate to identify and implement further ways to improve. This reinforces the cultural changes to build trust and confidence.
Introducing a DevOps methodology into an organization is not easy if the existing culture is not addressed first. It takes a vision and commitment from management and employees. This may require educating executives and management on the DevOps concept and principles if they are unfamiliar with them. Culture change starts from the top and flows downward through the organization, while processes are developed from the bottom and flow upward. Both of these concepts will be supported by the values of the company as a whole. Encouraging an agile mindset to team members who may have not worked under this type of methodology may take some time, but communicating the benefits of how both development and operations can work together for the benefit of the company should help.