April 26, 2019 at 16:39DevOpsForum 2019. Deploy DevOps can't wait
I recently visited DevOpsForum 2019 hosted by Logrocon. At this conference, participants tried to find solutions and new tools for the effective interaction of business and specialists in the development and information technology services.
The conference was a success: there were really a lot of useful reports, interesting presentation formats and a lot of communication with the speakers. And it’s especially important that no one tried to sell me anything, than the speakers at large conferences have lately blamed.
Squeezing from Raiffeisenbank's speeches, Alfastrakhovanie, the experience of Mango Telecom in the implementation of automation and other details under the cut.
Usually, I go hunting for interesting speakers on the sidelines. At DevOpsForum 2019, a speaker from Raiffeisenbank, Mikhail Bizhan, got into my field of interest. During the speech, he told how they are steadily planting their teams on DevOps, why they need it and how to sell the idea of DevOps transformation to business. Well, in general, I talked about how to see the light at the end of the pipeline.
Mikhail Bizhan, Director of Automation at Raiffeisenbank.
Now their company does not have “DevOps”. That is, he is true, but not in all teams. When implementing DevOps, they rely on the willingness of teams both from the point of view of specific engineers, and from the point of view of product needs and the maturity of the platform on which this product is built. Misha told how to explain to the 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 customer base is the opposite. If competitors produce an objectively cool product, all customers go there, then over time the market will equalize. Therefore, the launch of new products on 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 the business understands this.
The following important note: DevOps does not always reduce time to market. DevOps cannot work alone, it is only part of the process of creating and launching a product on the market from development to production (from code to client). But everything before 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. You need 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 the goal. Therefore, first of all, Raiffeisenbank agreed with the business that it was necessary to learn how to use DevOps. Automation for the sake of automation will not greatly help in the struggle for new customers.
In general, Misha believes that DevOps should be implemented, but wisely. And you have to be prepared for the fact that at the beginning of the transformation the team will lose productivity, it will earn less money, but then it will come true.
Yegor Maslov from Mango Telecom made another interesting report for me as a tester. The presentation was called "Automation of the full test cycle in the SCRUM team." Egor believes that DevOps was created specifically for SCRUM, but at the same time, introducing DevOps into the SCRUM team is quite problematic. This is because the SCRUM team is always running somewhere, there is no time to be distracted by innovations and rebuild the process. The problem also lies in the fact that SCRUM does not imply sub-teams (team of testers, development team, etc.). Well, in addition, documentation is needed to automate the existing process, and in SCRUM most often there is no documentation at all - “a product is more important than some kind of scribble”.
After switching to SCRUM, testers began to consult with developers on how to test features. Gradually, the volume of functionality increased, the documentation was missing, and they began to catch many 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 reeling. We decided to switch to testing automation. But then there was a complete fail. They attracted outsourced specialists for automation who wrote on a stack unknown to regular testers. The autotest framework certainly worked, but after the outsourcers left, he lived for two weeks. Then there 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: increase 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’ll direct plus, well, do not test your project in JavaScript with anything else). At the end of the sprint, they arranged a demo of how the autotest works, with the participation of the entire 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 be used accurately (and will not be commented out in a month due to constant failures).
Between the reports, I walked around the stands of the partners of the conference and pulled / won a lot of stuff. Eh, I love razdatku!
The cherry on the DevOpsForum 2019 cake for me was an hour-long plenary session with DevOps experts. Four participants were invited to watch DevOps from different angles: Anton Isanin (Alfastrakhovanie, Development Director), Naila Zamashkina (Fintech Lab, Operations Director), Oleg Egorkin (Rostelecom, Agile-coach) and Anton Martyanov (independent expert, looked at DevOps from a business perspective).
The experts sat closer to the people and it started: for an hour the participants from the audience asked their questions, and the experts puffed out. Sometimes a real debate came out. The questions were very different, for example: are DevOps engineers needed at all, why can’t they grow from system administrators, should DevOps be offered to everyone, what is its value and so on.
Then, I talked with Anton Isanin personally. We discussed the need to bring DevOps culture to every home and revealed the dark side of the DevOps transformation.
Imagine that everyone gathered and decided that DevOps is needed both for the product and for the business and the team. Rushed to introduce. Everything worked out. Exhaled. DevOps 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 constantly figures out defects for the product, creates a bunch of applications. Moreover, all defects come with the status of "urgent", even if the client suddenly wanted to paint the button in 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 hires another 10 people to keep up with the defects, and development hires another 15 to keep up with them. And instead of introducing new features, the team works with endless SD's, explaining the functionality to the user and support for one. As a result, both Ops and development are at work, but the client and business are unhappy: new features get stuck. It turns out that DevOps seems to be there, but it doesn't seem to be.
About the need to implement DevOps, Anton unequivocally stated that this directly depends on the scale of the business. If servicing 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 so chocolate. But if the business grows, more customers appear, then we must already comply. As a rule, the company has no cool Ops initially. First we saw the product, and only then we understand that the product should work, you need to look at the servers, monitor the deliveries. Then Ops arises. It remains to be understood that Ops, as a separate unit, will begin to expose a bunch of barriers to development and all deliveries will begin to stall. That is, in this case, the DevOps culture is already relevant, but you must not forget about its dark side.
The conference was a success: there were really a lot of useful reports, interesting presentation formats and a lot of communication with the speakers. And it’s especially important that no one tried to sell me anything, than the speakers at large conferences have lately blamed.
Squeezing from Raiffeisenbank's speeches, Alfastrakhovanie, the experience of Mango Telecom in the implementation of automation and other details under the cut.
My name is Yana, I work as a tester, I am engaged in automation, as well as DevOps and I love going to conferences and meetings. Over the past two years, I have been to Oleg Bunin's 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 - to 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 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 go hunting for interesting speakers on the sidelines. At DevOpsForum 2019, a speaker from Raiffeisenbank, Mikhail Bizhan, got into my field of interest. During the speech, he told how they are steadily planting their teams on DevOps, why they need it and how to sell the idea of DevOps transformation to business. Well, in general, I talked about how to see the light at the end of the pipeline.
Mikhail Bizhan, Director of Automation at Raiffeisenbank.
Now their company does not have “DevOps”. That is, he is true, but not in all teams. When implementing DevOps, they rely on the willingness of teams both from the point of view of specific engineers, and from the point of view of product needs and the maturity of the platform on which this product is built. Misha told how to explain to the 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 customer base is the opposite. If competitors produce an objectively cool product, all customers go there, then over time the market will equalize. Therefore, the launch of new products on 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 the business understands this.
The following important note: DevOps does not always reduce time to market. DevOps cannot work alone, it is only part of the process of creating and launching a product on the market from development to production (from code to client). But everything before 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. You need 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 the goal. Therefore, first of all, Raiffeisenbank agreed with the business that it was necessary to learn how to use DevOps. Automation for the sake of automation will not greatly help in the struggle for new customers.
In general, Misha believes that DevOps should be implemented, but wisely. And you have to be prepared for the fact that at the beginning of the transformation the team will lose productivity, it will earn less money, but then it will come true.
Test Automation at Mango Telecom
Yegor Maslov from Mango Telecom made another interesting report for me as a tester. The presentation was called "Automation of the full test cycle in the SCRUM team." Egor believes that DevOps was created specifically for SCRUM, but at the same time, introducing DevOps into the SCRUM team is quite problematic. This is because the SCRUM team is always running somewhere, there is no time to be distracted by innovations and rebuild the process. The problem also lies in the fact that SCRUM does not imply sub-teams (team of testers, development team, etc.). Well, in addition, documentation is needed to automate the existing process, and in SCRUM most often there is no documentation at all - “a product is more important than some kind of scribble”.
After switching to SCRUM, testers began to consult with developers on how to test features. Gradually, the volume of functionality increased, the documentation was missing, and they began to catch many 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 reeling. We decided to switch to testing automation. But then there was a complete fail. They attracted outsourced specialists for automation who wrote on a stack unknown to regular testers. The autotest framework certainly worked, but after the outsourcers left, he lived for two weeks. Then there 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: increase 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’ll direct plus, well, do not test your project in JavaScript with anything else). At the end of the sprint, they arranged a demo of how the autotest works, with the participation of the entire 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 be used accurately (and will not be commented out in a month due to constant failures).
By the way, an open microphone worked at DevOpsForum 2019 - a long-known and, in my opinion, useful format of performances. You walk like that, listen to reports, and then decide that it is worth discussing a topic or problem within the framework of the conference, and 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 questions come. Thus, you can cover a lot of topics at once and pester questions to speakers who are interested.
Between the reports, I walked around the stands of the partners of the conference and pulled / won a lot of stuff. Eh, I love razdatku!
Round table and DevOps questions with Alfastrah Development Director
The cherry on the DevOpsForum 2019 cake for me was an hour-long plenary session with DevOps experts. Four participants were invited to watch DevOps from different angles: Anton Isanin (Alfastrakhovanie, Development Director), Naila Zamashkina (Fintech Lab, Operations Director), Oleg Egorkin (Rostelecom, Agile-coach) and Anton Martyanov (independent expert, looked at DevOps from a business perspective).
The experts sat closer to the people and it started: for an hour the participants from the audience asked their questions, and the experts puffed out. Sometimes a real debate came out. The questions were very different, for example: are DevOps engineers needed at all, why can’t they grow from system administrators, should DevOps be offered to everyone, what is its value and so on.
Then, I talked with Anton Isanin personally. We discussed the need to bring DevOps culture to every home and revealed the dark side of the DevOps transformation.
Imagine that everyone gathered and decided that DevOps is needed both for the product and for the business and the team. Rushed to introduce. Everything worked out. Exhaled. DevOps 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 constantly figures out defects for the product, creates a bunch of applications. Moreover, all defects come with the status of "urgent", even if the client suddenly wanted to paint the button in 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 hires another 10 people to keep up with the defects, and development hires another 15 to keep up with them. And instead of introducing new features, the team works with endless SD's, explaining the functionality to the user and support for one. As a result, both Ops and development are at work, but the client and business are unhappy: new features get stuck. It turns out that DevOps seems to be there, but it doesn't seem to be.
About the need to implement DevOps, Anton unequivocally stated that this directly depends on the scale of the business. If servicing 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 so chocolate. But if the business grows, more customers appear, then we must already comply. As a rule, the company has no cool Ops initially. First we saw the product, and only then we understand that the product should work, you need to look at the servers, monitor the deliveries. Then Ops arises. It remains to be understood that Ops, as a separate unit, will begin to expose a bunch of barriers to development and all deliveries will begin to stall. That is, in this case, the DevOps culture is already relevant, but you must not forget about its dark side.