DevOps strategy for a tech company in 2021

Different companies may put different meanings into DevOps, so we will start with a couple of words about what this approach means for us. Although, we at True Engineering are not too original in this regard as our vision of DevOps is the same as by Amazon, Microsoft and other global development leaders.

DevOps is not a set of services and tools, but a methodology that blurs the boundaries between development teams, managers, support and implementation.

This approach speeds up and automates product creation, release preparation, and release. As a result, we have:

• Accelerating code assembly and deployment (CI/CD);

• Speeding up deliveries to the end user (Time-to-Market);

• Optimized manual procedures;

• Improved interaction among the teams, with the customer and with other participants in the work on the product.

Therefore, DevOps strategy includes project management approaches, team workflows, knowledge building measures, delivery processes, and infrastructure development.

In the end, all of this allows us to meet the requirements for the delivery process, and ensure predictability and reliability of our solutions.

We have already published articles on approaches to project management:

• How we created a common project template for all teams;

• How and why we moved the entire company to a single tracker in Azure DevOps;

• How our PMs build project analytics to keep updated with their products.

As a result, all our teams have a unified system of coordinates, unified principles, processes, and development standards.

Today we’re going to talk about how the DevOps guys build their strategy to make the delivery process as smooth and predictable as possible.

Infrastructure

The team has planned a gradual transition of all information systems to single templates. This process includes the following steps.

• Unification of Kubernetes clusters: converting to the same template, migrating to new versions, and building bundling with Ansible, GlusterFS, ELK.

• Nexus to Harbor repository migration for secure container handling, policy-based security access control, security check control.

• Switching business metrics and alerting from Zabbix to Prometheus.

• Updating related systems: MinIO, Gitlab, Nuget, SonarQube, NexusProxy, HAProxy, PostgreSQL, MongoDB, InfluxDB.

Tools

Our strategy includes both learning new tools and upgrading them to the status of standards, as well as consolidating knowledge in existing tools.

In the New Tools category, we explore solutions that provide better speed, either provide a greater level of safety or help get rid of manual labor.

For a detailed overview of our technology, we can refer readers to our technology radar. Here we will go over our main workhorses:

Image

Methodology

We have established a practice of transferring products to production Kubernetes clusters.

The DevOps team has worked out plans and checklists for project migration. The DevOps team has a well-established practice of communicating with development teams and customer engineers.

There is a set of tools that we can reuse: HELM chart templates, Gitlab\TFS pipelines.

The methodology of monitoring and working with various exporters of metrics is worked out to the last detail.

Processes

To keep all members of the DevOps team tuned, and to make it easier for newcomers to immerse themselves in the work, we thaw out key points:

• Planning: we teach how to properly plan the work and costs, taking into account possible risks in communications and technical details of solutions;

• Communications: we teach how to communicate properly with the development teams and the customer, so that the letter not sent on time did not cause problems;

• Mentoring: we accumulate knowledge, manage tasks and help solve difficulties that arise;

• On-call duty: we introduce the distribution of tasks and duty, so that an engineer is not buried under requests and messages in the personal. Instead of personal messages, we use duty chat, duty on incidents, so that the solutions of problems are periodically engaged in all in turn.

People

People are the most important and critical component. Our goal is to have DevOps professionals working on our projects, who differ from specialists in that they know the pros and cons of different tools and approaches, see the problem as a whole and can find the best way to solve it.

Over the past year, we’ve expanded our team of DevOps engineers and built a step-by-step process to get every new specialist up and running as quickly as possible. This basic training includes:

• studying books and courses;

• work on simulators;

• certification;

• and most importantly, practice in ongoing projects.

Of course, when you think about training DevOps engineers, you have to consider the specifics of the company. In our case, we pay a lot of attention to work with on premises infrastructure. Therefore, for us automation tools that many foreign companies work with, whose products are hosted in clouds by third-party providers, are less relevant.

What do we have at the bottom line?

All in all, it provides company management, PMs, and all teams with a strategic vision how True Engineering experts improve their competence, how to make the most of new techniques, and how to properly structure the work process.

Let’s finish with the same idea we started with that DevOps works not on technologies, but on processes. So, the most important thing is that specialists in a company understand their role in the development pipeline, so that the boundaries between different departments are drawn on a dotted line.

In this case, products will be developed faster because there will be no slow sections on the production lines. With such an approach, the technology used will only help the established processes.