I recently attended DevOpsForum 2019 hosted by Logrocon. At this conference, participants tried to find solutions and new tools for effective interaction between business and specialists in development and information technology services.
The conference was a success: there were really a lot of useful reports, interesting speech formats and a lot of communication with speakers. And it is especially important that no one tried to sell me anything, which is what speakers at big conferences have been doing lately.
An excerpt from the speeches of Raiffeisenbank, Alfastrakhovanie, Mango Telecom's experience in implementing automation and other details under the cut.
My name is Yana, I work as a tester, do automation, and also DevOps and I love going to conferences and meetups. Over the past two years, I have been at Oleg Bunin conferences (HighLoad++, TeamLead Conf), Jug events (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
First of all, I pay attention to the conference program. To a lesser extent, I look at what the report will be about, to a greater extent - at the speaker. Even if the report turns out to be very technological and interesting, it is not a fact that you will be able to apply some of the best practices from the report in your company. And then you need a speaker.
Light at the end of the pipeline at Raiffeisenbank
Usually, I organize a hunt for interesting speakers on the sidelines. At DevOpsForum 2019, a speaker from Raiffeisenbank, Mikhail Bizhan, was of interest to me. During the speech, he talked about how they progressively hook their teams on DevOps, why they need it, and how to sell the idea of DevOps transformation to the business. Well, in general, I talked about how to see the light at the end of the pipeline.
Mikhail Bizhan, Automation Director at Raiffeisenbank
Now they do not have “true DevOps” in the company. That is, he works, but not in all teams. When implementing DevOps, they rely on the readiness of teams, both in terms of specific engineers, as well as in terms of the need for the product and the maturity of the platform on which this product is built. Misha told how to explain to business why DevOps is needed.
The banking segment has several growth drivers: the cost of services and the expansion of the client base. Increasing the cost of services is not a very good driver, but the growth of the client base is the opposite. If competitors release an objectively cool product, all customers go there, then over time the market levels off. Therefore, the introduction of new products to the market and the speed of their launch is the main thing that banks are guided by. This is exactly what DevOps is for, and business understands this.
Another important note: DevOps does not always reduce time to market. DevOps cannot work alone, it is just part of the process of creating and bringing a product to market from development to production (from code to client). But everything up to the code has no direct relation to DevOps. That is, marketers can study the market for years and catch up with competitors all their lives. It is necessary to quickly understand what the client needs and plan the implementation of a particular feature - often this is not enough for DevOps to work and the company to achieve its goal. Therefore, first of all, Raiffeisenbank agreed with the business that it is necessary to learn how to use DevOps. Automation for the sake of automation will not help you much in the fight for new customers.
In general, Misha believes that DevOps needs to be implemented, but wisely. And we must be prepared for the fact that at the beginning of the transformation, the team’s productivity will decrease, it will earn less money, but then it will be justified.
Automation of testing in Mango Telecom
Another interesting report for me as a tester was made by Yegor Maslov from Mango Telecom. The presentation was called "Automation of the full cycle of testing in the SCRUM team." Egor believes that DevOps was created specifically for SCRUM, but at the same time, it is rather problematic to implement DevOps in a SCRUM team. This happens because the SCRUM team is always running somewhere, there is no time to be distracted by innovations and rebuild the process. The problem is also that SCRUM does not involve sub-teams in the team (team of testers, team of developers, and so on). Well, besides, to automate the existing process, documentation is needed, and in SCRUM most often there is no documentation at all - “the product is more important than some kind of writing”.
After switching to SCRUM, testers began to consult with developers on how to test features. Gradually, the scope of the functionality increased, the documentation was missing, and they began to catch a lot of bugs in the functionality in which there was no test coverage and in general it was no longer clear who and when tested it. In a nutshell - confusion and vacillation. We decided to switch to test automation. But even then there was a complete fail. They brought in outsourcing automation specialists who wrote on a stack unknown to full-time testers. The framework for autotests certainly worked, but after the outsourcers left, he lived for two weeks. Next was an attempt to introduce self-testing number two. It began with the fact that everything needs to be built within the company, on its own (the right vector: build up expertise inside), within the framework of SCRUM, and create documentation in the process. The stack for automation should be equal to the stack of the product (here I’m directly plus, well, don’t test your JavaScript project with something else). At the end of the sprint, they did a demo of how the autotest works with the whole team (useful). Thus, the involvement of all team members in the automation process increased, as well as trust in autotests and the chance that this autotest will definitely be used (and will not be commented out in a month due to constant failures).
By the way, an open microphone worked at DevOpsForum 2019 - a well-known and, in my opinion, useful format of speeches. You walk around like that, listen to reports, and then decide that within the framework of the conference it is worth discussing a certain topic or problem, sharing relevant experience in solving the problem.
I also noticed that the organizers made a stream of short reports. Each report lasts no more than 10 minutes, then there are questions. Thus, you can cover many topics at once and stick with questions to the speakers who are interested.
Between the reports, I walked around the stands of the conference partners and dragged / won a lot of stuff. Oh, I love the giveaway!
Round table and DevOps issues with the development director at Alfastrakhovanie
The icing on the cake at DevOpsForum 2019 for me was an hour-long plenary session with DevOps experts. Four session participants were invited to look at DevOps from different angles: Anton Isanin (Alfastrakhovanie, Development Director), Nailya Zamashkina (Fintech Lab, Operations Director), Oleg Egorkin (Rostelecom, Agile Coach) and Anton Martyanov (Independent expert, looked at DevOps from a business point of view).
The experts sat closer to the people, and then it started: for an hour, the participants from the audience asked their questions, and the experts puffed. Sometimes there were real debates. The questions were very different, for example: are DevOps engineers needed at all, why it is impossible to grow them out of system administrators, should DevOps be offered to everyone, what is its value, and so on.
Then, I talked to Anton Isanin personally. Discussed the need to bring the DevOps culture to every home and revealed the dark side of DevOps transformation.
Imagine that everyone got together and decided that DevOps is needed both for the product and for the business and the team. Rushed to implement. Everything worked out. Exhaled. DevOps has made us closer to the client, now we can quickly fulfill all his wishes. As a result, we have a large Ops division with strict regulations and requirements, and it all the time figurates defects on the product, creates a bunch of applications. Moreover, all defects go with the “urgent” status, even if the client suddenly wants to color the button yellow instead of green. The project is growing, the number of releases is growing and, accordingly, the number of defects and misunderstandings of new functionality by customers. Ops is hiring 10 more people to keep up with reporting bugs, and development is hiring 15 more to keep them closed. And instead of introducing new features, the team works with endless SD's, explaining the functionality to the user and support in one. As a result, both Ops and development are in business, but the client and business are unhappy: new features get stuck. It turns out that DevOps seems to exist, but it seems that it doesn’t.
About the need to implement DevOps, Anton clearly stated that it directly depends on the scale of the business. If serving one client a year brings the company a billion, DevOps is not needed (provided that you do not need to roll out new changes to this client regularly). Everything is in chocolate. But if the business grows, more customers appear, then you have to comply. As a rule, there is no cool Ops in the company initially. First, we saw the product, and only then we understand that in order for the product to work, we need to keep an eye on the servers, monitor the supplies. Then there is Ops. It remains to be understood that Ops, as a separate division, will begin to expose a bunch of barriers to development and all deliveries will begin to slip. That is, in this case, the DevOps culture is already relevant, but we must not forget about its dark side.
Source: habr.com