Earlier last year, we published an article titled: “DevOps: Here to stay, or just a trend?” that touched on elements of the DevOps movement, as well as it’s possible business impacts.
One year later, a lot of work has been done on DevOps and it’s now much more than just a simple trend. We thought it was a good time a year later to go back and talk about DevOps again, while also giving you a few tips on how to implement DevOps in your business.
Be Transparent and Collaborative
The main idea behind DevOps is that the Dev side, developing the code for your products and the Ops side, handling the good operating of the systems, weren’t communicating with each other very well, often not communicating at all. This led to different visions and objectives, bringing more chokepoints, slowing down your processes and service delivery (i.e.: only one developer that can understand and modify a crucial part of code, with, of course, no documentation to help you in the eventuality that the said developer is unavailable).
Therefore, the sharing of knowledge and good communication, is fundamental in DevOps, from which it’s practices were made in order to improve on those two points.
DevOps is, first and foremost, a matter of Corporate Culture, bringing an increased, continuous collaboration between the Development side and the Operations side. Therefore, the communication level and the sharing of information between those sides is the main change that occurs when introducing DevOps in a workplace. Not introducing this and still trying to work in DevOps will defeat the purpose of the change and ultimately fail.
To bring this collaboration to your workplace, a practical way is to include your system administrators in your agile development process (Which DevOps originates from), where they’ll be able to give their input. You can also have some developers spend more time to help support. This will confront them with their code and customer’s issues, ultimately making your developers better coders. To make the sharing of information easier, make it a habit to document your projects and processes, if you’re not doing it already.
Get to know the people around you
Collaboration also comes with knowing who we’re working with. Try to learn what motivates people, what doesn’t, who they are. Not only is this good for DevOps, but it also helps with creating a good work environment. Try to involve those people and transform them in actors inside you DevOps process. This also applies when interacting with clients, that also have to be involved in the process.
The implication of all these actors, going from the developer to the user, allows them to better understand and better define needs and requirements. This results in a not only a faster service delivery, but also in the right service delivery.
Also necessary is the diversification of the skills of IT teams. No longer can you have developers and programmers that only stay in front of their screens writing code, or an IT director that doesn’t have at least some programming skills. To function properly, DevOps needs people with both Dev skills and Ops skills. These people in a workforce are very important, as they will be the ones building bridges and creating the foundation of the communication that is vital for DevOps.
Focus on Chokepoints
This is key for every kind of service delivery and not only for DevOps. Don’t hesitate to review your processes and fix the area where they stall or block. Often, time can be lost by waiting for approvals in a change process forexample, or simply trying to find who’s to blame for the latest incident. A better communication in DevOps not only allows people to better understand what happens throughout the whole process, but also has the added benefit of finding a fixing the areas where chokepoints are.
Working in DevOps generally prevents backtracking, losing efficiency and wasting time on work that has already been done. Too often before, there was a disparity between what the client needed and what was created by the developer. With DevOps, being in constant communication with all the actors of a process, you avoid miscomprehensions and find a renewed efficiency.
Furthermore, DevOps is not an exclusive management philosophy, or contradicting other methods: An Agile methodology for instance, can be combined with a DevOps management philosophy. It must be stressed however, that DevOps is not as simple as using a magic wand and does not solve every problem that could exist in an IT department. Applying DevOps in an IT environment is something that requires a lot of work and adaptation.
Know your processes, eliminate distractions and use good methods
There’s also undoubtedly a technological aspect to the implementation of a DevOps philosophy and that comes with the use of automation. Too often you see a project working in a testing environment and then, by sending it live, brand new bugs appear.
IT teams cannot be spending all their time dealing with incidents and fixing bugs. This affects the communication between teams. So, in order to deal with those frequent and repetitive tasks, processes like your deployment, testing and integration processes can be automated. Otherwise, as stated, communication suffers, from the developer, all the way to the client.
DevOps is a Continuous approach
We’ve talked about this throughout the entire article, but it is important to insist on that point; a continuous approach for improvements and communication is fundamental in DevOps. Take some time during the week to meet your teams, go back and discuss on what was done, what went wrong, what went right. Then, focus on what’s coming: what are the plans for next week? What do you need to reach your goals? What issues are you facing? This will put everyone on the same page.
Continuity is at the basis of DevOps. The process never really stops. Testing is constant, updates and deliveries are quick and communication channels are constantly open. With great DevOps practices, comes a great responsibility to maintain them.