DevOpsForum 2019. DevOps cannot be injected
I recently visited DevOpsForum 2019, which was arranged 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 many useful reports, interesting formats of speeches and a lot of communication with the speakers. And it is especially important that no one tried to sell me anything, as the speakers at big conferences have been sinning lately.
')
Squeeze out of speeches Raiffeisenbank, Alfastrakhovaniya, the experience of Mango Telecom in the implementation of automation and other details under the cut.
Usually, I hunt interesting speakers on the sidelines. At DevOpsForum 2019, a speaker from Raiffeisenbank, Mikhail Bizhan, got into my field of interest. During his speech, he told how they progressively set 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 they don’t have “true DevOps” in their company. That is, he is laboring, but not in all teams. When implementing DevOps, they rely on the willingness of teams, both in terms of specific engineers, in terms of product needs and the maturity of the platform on which this product is built. Misha told how to explain the business why DevOps is needed.
The banking segment has several growth drivers: the cost of services and the expansion of the customer base. Increasing the cost of services is not a very good driver, but the growth of the client base is the opposite. If competitors produce an objectively cool product, all customers go there, then the market will level out over time. Therefore, the launch of new products on the market and the speed of their launch is the main thing that banks are guided by. Just for this, you need DevOps, and the business understands this.
Next 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 design 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 just not enough for DevOps to work and the company to achieve the goal. Therefore, first of all, in Raiffeisenbank we agreed with the business that it is necessary to learn how to use DevOps. Automation for the sake of automation is not much help in the fight for new customers.
In general, Misha believes that DevOps needs to be implemented, but with the mind. And we must be prepared for the fact that at the beginning of the transformation, the team will drop productivity, it will earn less money, but then it will be justified.
Another interesting report for me as a tester was made by Egor 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 quite problematic to implement DevOps into the SCRUM command. This is because the SCRUM team runs somewhere all the time, there is no time to be distracted by innovations and to restructure the process. The problem also lies in the fact that SCRUM does not involve sub-teams in the team (a team of testers, a team of developers, and so on). Well, and besides, to automate an existing process, documentation is needed, and in SCRUM, documentation is most often not fully available - “the product is more important than some kind of writings”.
After switching to SCRUM, testers began to consult with developers how to test features. Gradually, the amount of functionality increased, there was no documentation, and they began to catch a lot of bugs in the functionality in which there was no test coverage and it is not at all 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 attracted outsourcing automation specialists who wrote on an unknown stack for in-house testers. The autotest framework certainly worked, but after the outsourcers left, he lived for two weeks. Next was an attempt to introduce auto-test number two. It began with the fact that everything needs to be built within the company, on its own (the correct vector: increase expertise inside), within the framework of SCRUM, and in the process of creating documentation. The stack for automation should be equal to the product stack (right here, plus, you don’t test the JavaScript project with something else). At the end of the sprint, they organized a demo of how the autotest works, with the participation of the whole team (useful). Thus, the involvement of all team members in the automation process increased, as well as confidence in autotests and the chance that this auto test will be used for sure (and will not be commented out after a month due to constant failures).
Between the reports I walked around the stands of the conference partners and dragged / won a lot of all sorts of things. Oh, I love razdatku!
Cherry on the DevOpsForum 2019 cake for me was an hourly plenary session with DevOps experts. Four participants of the session were invited, who were supposed to look at DevOps from different sides: Anton Isanin (Alfa Insurance, Development Director), Naila Zamashkina (Fintech Lab, Operations Director), Oleg Egorkin (Rostelecom, Agile-Coach) and Anton Martyanov (Independent the 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 took the rap. Sometimes there was a real debate. The questions were very different, for example: are there any need for DevOps engineers at all, why it is impossible to grow them from system administrators, whether we should offer DevOps to everyone, what is its value and so on.
Then, I talked with Anton Isanin personally. We discussed the need to carry the DevOps culture into every home and uncovered the dark side of the DevOps transformation.
Imagine that everyone gathered and decided that DevOps is needed for both the product and the business and team. Rushed to introduce. Everything worked out. Breathed out. DevOps made us closer to the client, now we can quickly fulfill all his wishes. As a result, we have a large division of Ops with strict regulations and requirements, and it all the time figuring defects on 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 grows, the number of releases grows and accordingly the number of defects and misunderstandings of new functionality by customers. Ops hires another 10 people to keep up with defects, and the development takes another 15 people to keep them closed. And instead of introducing new features, the team works with infinite SD's, explaining the functionality to the user and the support for one thing. As a result, both Ops and development are in business, but the client and business are unhappy: new features are stuck. It turns out that DevOps seems to be there, but it seems like it doesn't.
About the need to implement DevOps, Anton unequivocally stated that this directly depends on the size of the business. If servicing one client per year brings a billion to the company - DevOps is not needed (provided that you do not need to roll out new changes to this client regularly). All so and 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. First, we saw the product, and only then we understand that in order for the product to work, you need to look behind the servers, monitor the deliveries. Then there is Ops. 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 slip. That is, in this case, the culture of DevOps is already relevant, just need not forget about its dark side.
The conference was a success: there were really many useful reports, interesting formats of speeches and a lot of communication with the speakers. And it is especially important that no one tried to sell me anything, as the speakers at big conferences have been sinning lately.
')
Squeeze out of speeches Raiffeisenbank, Alfastrakhovaniya, 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, do automation, as well as DevOps and adore attending conferences and meetings. Over the past two years, I was at the conferences of Oleg Bunin (HighLoad ++, TeamLad Conf), at Jug events (Heisenbug, JPoint), at 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, and to a greater extent, at the speaker. Even if the report turns out to be very technological and interesting, it’s not a fact that you can 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 in Raiffeisenbank
Usually, I hunt interesting speakers on the sidelines. At DevOpsForum 2019, a speaker from Raiffeisenbank, Mikhail Bizhan, got into my field of interest. During his speech, he told how they progressively set 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 they don’t have “true DevOps” in their company. That is, he is laboring, but not in all teams. When implementing DevOps, they rely on the willingness of teams, both in terms of specific engineers, in terms of product needs and the maturity of the platform on which this product is built. Misha told how to explain the business why DevOps is needed.
The banking segment has several growth drivers: the cost of services and the expansion of the customer base. Increasing the cost of services is not a very good driver, but the growth of the client base is the opposite. If competitors produce an objectively cool product, all customers go there, then the market will level out over time. Therefore, the launch of new products on the market and the speed of their launch is the main thing that banks are guided by. Just for this, you need DevOps, and the business understands this.
Next 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 design 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 just not enough for DevOps to work and the company to achieve the goal. Therefore, first of all, in Raiffeisenbank we agreed with the business that it is necessary to learn how to use DevOps. Automation for the sake of automation is not much help in the fight for new customers.
In general, Misha believes that DevOps needs to be implemented, but with the mind. And we must be prepared for the fact that at the beginning of the transformation, the team will drop productivity, it will earn less money, but then it will be justified.
Automation testing in "Mango Telecom"
Another interesting report for me as a tester was made by Egor 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 quite problematic to implement DevOps into the SCRUM command. This is because the SCRUM team runs somewhere all the time, there is no time to be distracted by innovations and to restructure the process. The problem also lies in the fact that SCRUM does not involve sub-teams in the team (a team of testers, a team of developers, and so on). Well, and besides, to automate an existing process, documentation is needed, and in SCRUM, documentation is most often not fully available - “the product is more important than some kind of writings”.
After switching to SCRUM, testers began to consult with developers how to test features. Gradually, the amount of functionality increased, there was no documentation, and they began to catch a lot of bugs in the functionality in which there was no test coverage and it is not at all 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 attracted outsourcing automation specialists who wrote on an unknown stack for in-house testers. The autotest framework certainly worked, but after the outsourcers left, he lived for two weeks. Next was an attempt to introduce auto-test number two. It began with the fact that everything needs to be built within the company, on its own (the correct vector: increase expertise inside), within the framework of SCRUM, and in the process of creating documentation. The stack for automation should be equal to the product stack (right here, plus, you don’t test the JavaScript project with something else). At the end of the sprint, they organized a demo of how the autotest works, with the participation of the whole team (useful). Thus, the involvement of all team members in the automation process increased, as well as confidence in autotests and the chance that this auto test will be used for sure (and will not be commented out after 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 speeches. You walk around like this, listen to reports, and then decide that it is worth discussing a certain topic or problem at the conference, sharing relevant experience in solving a 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 speakers who are interested.
Between the reports I walked around the stands of the conference partners and dragged / won a lot of all sorts of things. Oh, I love razdatku!
Round table and DevOps questions with the director of development in Alfastrakhovanie
Cherry on the DevOpsForum 2019 cake for me was an hourly plenary session with DevOps experts. Four participants of the session were invited, who were supposed to look at DevOps from different sides: Anton Isanin (Alfa Insurance, Development Director), Naila Zamashkina (Fintech Lab, Operations Director), Oleg Egorkin (Rostelecom, Agile-Coach) and Anton Martyanov (Independent the 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 took the rap. Sometimes there was a real debate. The questions were very different, for example: are there any need for DevOps engineers at all, why it is impossible to grow them from system administrators, whether we should offer DevOps to everyone, what is its value and so on.
Then, I talked with Anton Isanin personally. We discussed the need to carry the DevOps culture into every home and uncovered the dark side of the DevOps transformation.
Imagine that everyone gathered and decided that DevOps is needed for both the product and the business and team. Rushed to introduce. Everything worked out. Breathed out. DevOps made us closer to the client, now we can quickly fulfill all his wishes. As a result, we have a large division of Ops with strict regulations and requirements, and it all the time figuring defects on 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 grows, the number of releases grows and accordingly the number of defects and misunderstandings of new functionality by customers. Ops hires another 10 people to keep up with defects, and the development takes another 15 people to keep them closed. And instead of introducing new features, the team works with infinite SD's, explaining the functionality to the user and the support for one thing. As a result, both Ops and development are in business, but the client and business are unhappy: new features are stuck. It turns out that DevOps seems to be there, but it seems like it doesn't.
About the need to implement DevOps, Anton unequivocally stated that this directly depends on the size of the business. If servicing one client per year brings a billion to the company - DevOps is not needed (provided that you do not need to roll out new changes to this client regularly). All so and 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. First, we saw the product, and only then we understand that in order for the product to work, you need to look behind the servers, monitor the deliveries. Then there is Ops. 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 slip. That is, in this case, the culture of DevOps is already relevant, just need not forget about its dark side.
Source: https://habr.com/ru/post/449666/
All Articles