Five tips for applying DevOps in your company

Along with agile transformation in large enterprises, a growing second wave is DevOps as a transformative force in the software development process. But where to start? How to create a basis for this culture to develop solidly and sustainably?

See in this article 5 essential steps you need to take to effectively apply DevOps and three traps that companies always fall into. In addition to reading about relevant points such as concepts, history, and our experience.

The DevOps concept

DevOps – Development + Operation – this junction of the two words indicates a (re)union of development practices with the operation, meaning a continuous flow without hand-offs in delivering a feature or system.

But why was there this rupture? Who doesn’t remember the old programmers who talked to customers, developed the system from end to end and deployed it in complex and constrained environments? Why don’t we have these people with such ability anymore? Where did we get lost?

How DevOps became a popular term

In the 1990s, in search of false efficiency, development processes were redesigned according to the type of work performed. Responsibilities were defined by practices and no longer by value deliveries.

Based on the manufacturing industry, such a model expected that each part of a flow, working in a specialized way, would make the whole more efficient, generating high productivity and quality.

Thus were born the silos of Analysts, Devs BackEnd, Devs FrontEnd, Testers, Operation, etc. That is, groups that are highly efficient in carrying out their activities but rarely have a commitment or even knowledge of the value delivered at the end of the process.

A highly formal model brought a fundamental error: software development has no analogy with industrial production, as it does not generate repeatable deliveries as a product or from a similar set of raw materials (initial contexts).

Software construction processes are, in fact, much more analogous to artisans who employ organized creative actions to achieve a fully known result only after it is ready.

Unfortunately, such an erroneous model still potentiated its negative impact as it justified its failure as insufficiency of more formalism. To try to ‘correct’ the disastrous result, more prescriptions, definitions, and protocols were applied and, thus, further distanced each one from the commitment to the value of what was being done. It was the Age of Process for Process’s sake.

A light was illuminated with the advent of the agile development mindset, combined with the movement to focus on customer value as the driving force of any business.

Finally, the inability of silo models to truly deliver value in line with the changing expectations of users was realized. We can no longer afford to have more powerful contracts than satisfying needs.

Then comes the DevOps culture. A set of mindsets, practices, and automation with the principle that development is only ready if used in production by the customer.

Three pitfalls of DevOps

Although the reunification of the DevOps process (development with operation) seems evident and natural, such action has been painful for most companies, especially large organizations.
This is due to the high expertise that has been sought in recent decades in specific activities, combined with their departmentalization.
In an attempt to break down such barriers, many leaders end up taking non-assertive responses, which translate into traps:

1- DevOps Specialists

The term DevOps should not be used for a specific professional.
DevOps culture means integrating delivery and development, a characteristic that a team must have and not specific people. Thus, the search should be for people capable of, as a team, delivering their development directly into production. Specialists should prioritize disseminating their knowledge to the team, and the team should be responsible for the delivery itself.

2- DevOps Team

Another widespread mistake found in many organizations is the creation of ‘DevOps teams.’ They create teams responsible for automating processes and supporting tools used by the development team. Like the trap mentioned above, this practice does not bring together the commitment to integrate development with delivery.
The ideal is that such a culture is within each development team, and they are responsible for the process automation. Of course, joint efforts between teams are significant for efficiency, but this must be conducted using guilds or even own development projects.

3- Local DevOps Application

Many companies use the DevOps culture by applying a high degree of automation to support agile initiatives within specific teams or projects.

If applied to restricted contexts, such an approach has the opposite effect to what is expected. When performing local optimization, bottlenecks are invoked in other areas or even cases of starvation (interruptions due to lack of requirements).

These scenarios can generate more conflicts or disturbances that sometimes cause the opposite effect to what is expected, worsening the general condition of the team or the project instead of improving it.
The five essential steps

The five essential steps

When we talk about DevOps, many questions immediately appear: How to start? How to make it sustainable? How to climb How to avoid waste?

Below, I list some of the steps that I consider fundamental for the beginning of implementing a DevOps culture in organizations, regardless of their size.

These are the initial steps so that the other practices are based, and the growth is continuous, lasting, and with the best delivery of value.

1- Start at the End – Automated Tests form the foundation

Test automation was one of the first practices that adopted agile transformation methodologies. However, even today, very few companies employ it effectively. Automation and DevOps practices rely heavily on a culture of automated testing being present in the company. Start with what you have today:

1. Implement automated tests on found bugs. No bug is considered fixed until it has an automated test to reproduce it.
2. Implement automated tests only on new features developed
3. Automate legacy tests on an ongoing basis. Only when there is a need to change these
4. Use schema evolution (a technique for automated database creation) so that your tests do not depend on previous bases
5. Adopt frameworks that allow robustness for the creation of test scripts
6. Don’t focus on tests involving robots or system screens. In contrast, unit and functional tests are faster to build and run and more robust (easier to maintain and scale).

2- Evolve with consistency – Implement small changes, validate and define

To succeed in applying DevOps practices, don’t try to change everything at once. Instead, implement just one process/automation, start monitoring and measuring this one, and then move on to a second evolution.

Just like the steps for implementing automated tests, grow consistently.

The rule is simple: for each process or automation applied, all team members start to use it so that it is really valuable and stressed to obtain the best benefit. If the team cannot evolve with the improvement, reconsider and discard. Don’t keep things that don’t bring value to the team.

3- One-Click Principle – Standardization generates robustness

Processes and automation are pretty sensitive in heterogeneous environments.

As much as the independence of teams is accepted or even valued when it is translated into individual configurations, this becomes very harmful for the insertion of DevOps practices.

To control this, invest in the development of ‘One Click’ mechanisms, that is, systems capable of, with just one click, assembling a complete station and leaving it operational. Also, with these systems, it is possible to set up server environments, databases, test servers, and the entire set of artifacts necessary for the development environment used.

Standardization will also strengthen robustness as the phrase ‘works on my machine’ will no longer make sense as they all share the same configuration and environment.

4- To Infinity and Beyond – All in the Cloud

The advent of cloud computing has become a great ally in the evolution of the DevOps culture.
Replication of virtual environments is much faster, safer, and more robust.

In addition, the evolution of memory, processing, space, and connectivity are also no longer critical issues.
Invest without fear in this technology. Several options are offered, and many tools are already ready to facilitate the controls.

With reasonable control, it is possible to leave all this infrastructure at a lower cost than onsite infrastructure and practically infinite scalability.

Production environments and even development can take advantage of these benefits and open horizons to practices that were impossible before. Imagine, for example; you have a complete production environment replicated for each developer and renewed for each feature they develop.

5- Quality – Autonomy, time, and responsibility

The term ‘qualitivity’ is something we created here at Objective to indicate the time each person spends improving their productivity. It’s not time for product development but improvements to make productive time as efficient as possible.

For DevOps practices, this is fundamental: all developers have availability so they can help improve their processes.

How much? Start with 20% and increase as needed.

In observations, we saw that 40% of the time invested in improvements brings the most significant benefit in terms of productivity and quality for high-performance teams.

This translates into an immediate improvement in effectiveness as it allows real-time development to be truly valuable and focused on what matters to customer satisfaction.

Do you have questions or want to know a little more about each of the steps on DevOps? If you’re going to delve deeper into the subject or need help implementing it in your company, talk to our experts now.