What does DevOps mean, when you can search the term on Google and find so many different descriptions? The basic idea behind DevOps is to put the two roles of Dev (Developer and all the roles of development) and Ops (Operations) together to get the two traditional roles working together in a new way. While this basic description sounds somewhat obvious, you need to think about how these two roles have traditionally been implemented before we can describe the new DevOp role.
What is DevOps?
The job of a software developer is to create change. A developer takes the user requirements and creates or alters a program to provide a solution to a known problem.
The traditional role of Operations is usually responsible for keeps processes running by focusing on up-time and system reliability. This usually means taking the programs provided and not allowing anything to change.
So we jam these two roles together into one role, and from the beginning the incentives for one role are misaligned with the other. The first thing that is required to implement DevOps is to break down the walls between the two roles. The idea of developers and operators working together, looking for ways to make improvements and understanding how the software is created and used is the idea behind this new role.
How Do You Do It?
There are two basic ways of implementing DevOps in your environment.
Rotation – You rotate the developers into the role of operations. While the details of what that means is slightly different from company to company, the idea is basically to have the programmer use and support the programs they create. It offers a deeper insight into the day to day use of the software, what issues they users encounter, and why potential improvements would really make the product better for the users. This can usually be done with a rotation schedule frequent enough to allow the developer operational access a few months in each year, or maybe as often as three months on and three months off.
Responsibility – Another possibility is to keep the developer in their primary role as developer all the time, but expose them to more operations through supporting and using the product most of the day. This means building, deploying, supporting, training, etc. This would give the developers broad exposure to how their programs are used, and also help them feel the pain of supporting their own work. You will still need operations support personnel to do most of the day to day operations of supporting business operations, but you make sure the developers are directly involved as well.
Can You Do It?
This new role requires potentially changing much of what a developer thinks he can and should be doing, an this isn’t something that can be completed with sending out an memo or announcing the change at a weekly meeting. You have to clearly define how you are going to do this change at your company, solicit feedback from everyone involved, and fully document how it is supposed to work from day one.
One problem that is often overlooked is compliance. The obvious issue is developers shouldn’t have access to production systems. When developers have access to the production systems and make changes to how those systems operate, you may run into compliance issues with your auditors. You must maintain strict controls on how program changes are requested, approved, made, and promoted. Automation of the build and deploy process is your friend.
Another problem is with the volume of changes. Once developers see how the program is actually used and what problems need to be solved, you can expect a wave of ideas for rewrites and alterations. This is something that is both welcome and hated. You will have to manage the flow of ideas and change requests to keep the developers focused on business solutions.
What Happens Next?
You need to really understand the concepts of DevOps, and how it can make your operations better before you change anything. Make sure you understand what you want to change and how you can measure any improvement before you make any changes. You should set goals and don’t be afraid to make new changes if your initial changes don’t yield the results you expected.
You can read more on Wikipedia, where it is said:
The specific goals of a DevOps approach span the entire delivery pipeline. They include improved deployment frequency, which can lead to faster time to market, lower failure rate of new releases, shortened lead time between fixes, and faster mean time to recovery in the event of a new release crashing or otherwise disabling the current system. Simple processes become increasingly programmable and dynamic, using a DevOps approach, which aims to maximize the predictability, efficiency, security, and maintainability of operational processes. Very often, automation supports this objective.