The adoption of a culture as DevOps generates many impacts and therefore benefits and mistakes. Change the day-to-day of many people. A large corporation that decides to adopt DevOps should have multiple care because a lot of resistance will emerge.
For DevOps to be effective, some people will have to leave their comfort zone. Shoud have training, change in the way of work and adoption of new tools. And all this must be very well orchestrated so that it can happen as painlessly as possible.
But even taking all care possible, many mistakes are made during the adoption of DevOps. And these errors can trigger stress, rework, financial losses and even result in the end of the project with a partial or improper adoption.
Observing some companies that already have gone through the DevOps adoption process – even a small adoption – I realized that many mistakes are made. And many of them are recurring among companies.
Thinking about it, this is a list of some observed errors, aiming to avoid them when a DevOps adoption project is running.
- Do not have an implementation plan: The changes caused by the adoption of DevOps can be as simple as changing the level of a log or as complex as rewriting an entire application module so that it can be scalable and configurable. This requires planning and an implementation plan, splitted by iterations, listing the involved people and each responsibility. The adoption of DevOps should be incremental, with continuous improvement and PDCA cycles. In fact, it is an eternal transition, because there always will be new tools, technologies and integrations in the process;
- Try to adopt DevOps without change the process: A lot or almost everything can be changed with the adoption of DevOps. And the processes, the way to do the tasks should be changed, documented and approved. Processes such as the software development, change management and configuration management are usually the most affected;
- Consider DevOps is only adoption of tools: in fact, the tools are much of what should be done. But it is a common mistake thing that tools are only what should be done. We can not forget to change processes, conduct training and test everything;
- Forget to consider the culture of the people: As far as the final product, people are affected in the adoption of DevOps. And they have their own culture, preferences and ways to deal with different situations. And it can be painful for some people. It is necessary that everyone understands that, even if your culture is affected and you do not like it, the changes are for the greater good.
- Do not get prior approval of all parties involved: When changing the tools and processes, some people may be linked affectively to them and resist the adoption of the changes. Obtaining approval is therefore gaining acceptance. Or at least the commitment to use;
- Do not document the process changes: People will not understand all changes in the first explanation. Nor in the second. And will forget some details. And they will question the usefulness and effectiveness of processes. Have a documented processes, including what changes were made, detailing the people who developed, tested and approved the processes will facilitate understanding and avoid unnecessary meetings and discussions;
- A not incremental adoption: You can make many changes, really! And if they are made all at once, people will not be able to assimilate it all. And they will have a hard time understanding why that is important. With iterations you can avoid this mistake and will be easier to absorb DevOps. Also dilute costs through the months;
- Do not be a responsible for continuous integration: Automating tasks greatly reduces the effort. But until everything is automated, there is some effort. Further, it is necessary to conduct tests. Adjustments always appear. Over time, the software changes the its build process. And these tasks are recurring. It is necessary that the continuous integration has one or more responsibles, dedicated exclusively or not to theses tasks, depending on the size of the effort;
- Think DevOps is only “one-click deploy”: Devops is not only is continuous integration nor only continuous delivery. It code more efficiently. It is involved in the operation in the development, and vice versa. And everything else that we expose here;
- Automating too much, each of small and simple processes, without yet having the maturity to this: Almost everything can be automated. Predictable tasks, which do not depend on decision-making and analysis should be automated. But make sure your process and your business are mature enough for this. To read in the internet that particular company, the developer commits a change and it automatically is deployed in production does not make your company is capable of it also.
- Try to automate when is not allowed: Every business has a specific process and requirements. It has characteristics that must be respected. And it may end up preventing some automations. For example, in a company in the financial sector where I had contact, before deployments in production, is required a written approval of the QA Lead.
- Do not be realistic about your systems: Think that everything can be implemented in every system is a mistake. Legacy applications tend to be tied to each other, to the architecture and the existing infrastructure in the company. Often all this is even documented and it is very risky for the company that its main business be interrupted. Use models of large companies like Google, Facebook, Amazon and Netflix may not work for your corporation;
- Failing to budget: A project without a budget is just a dream. It is true that DevOps reduces costs, increases the agility of the times and improves the quality of the product, but to get there, you have to spend. Investment in people, processes, technology and tools;
- Not test properly: Continuous delivery process, for example, is complex and repetitive. So it must be automated at all. And consequently, it must be tested. And retested. And tested again. A single failure in automation, not only will make your deliveries do not occur at the desired frequency, as will the whole process lose credibility, resulting in resistance in the acceptance and use of it. A failure in the automatism can also cause millions in financial losses if it occurs in production;
- Treat carelessly the environments: All environments should be controlled by rules. Frequency and time that the deployments can occur, who has access to them, and if they will have high availability and redundancy are some rules that each of their environments must have. Whether it’s a development environment, QA or production: they all must be controlled.