Wrike TechClub: Delivery infrastructure - processes and tools (DevOps + QAA). Papers in English

Hello, Habr! We at Wrike are testing new formats for technical events and we invite everyone to watch a video of our first online meeting in English. We talked about the DevOps infrastructure for testing web applications, cubes, Selenium and its alternatives.



The story of the spread of the coronavirus and the bans of all the massive offline events on the territory of European countries made their own corrections, so the offline meeting of testers and devs planned by Wrike Prague turned into YouTube.

Attention, reports in English.

1. Mikhail Levin, Wrike - Selenium - road to Kubernetes

Once upon a time Selenium lived and grew. It was probably the best thing that happened for QA automation in the last two decades, and yeah, that wasn't easy in many ways including infrastructure and stability.

With long experience in selenium grid infrastructure and alternatives, I want to walk you through some issues and limitations of different selenium infrastructures up to our brand new lightweight solution.



2. Vitaliy Markov, Wrike - Callisto: how we learned to stop worrying and love Selenium

Meet Callisto - our lightweight and open-source Kubernetes-native solution for building of Selenium infrastructure. We run 10th thousands of selenium tests in one hour and survive hundreds of daily selenium test runs with it. We want to share our reasons, the solution itself and technical details learned on the way. Our experience might come in handy whether you run that much of selenium tests or you just have some session based work to be run in k8s in many threads.



3. Ivan Krutov, Aerokube - Chrome Developer Tools Protocol: running and scaling in Kubernetes

Many years Selenium is the most popular browser automation tool. However, Selenium protocol still lacks a lot of important features: analyzing and mocking HTTP requests, getting memory consumption and performance metrics, subscribing to application events, retrieving browser security warnings and many more. Fortunately, all this stuff is already supported in the so-called Chrome Developer Tools protocol. There are a lot of talks on how to start using this protocol with client libraries like Puppeteer, but almost nobody tells how to scale this solution. During my talk, I would like to explain how to scale Chrome Developer Tools in Kubernetes cluster and to show some real examples of how you could use this protocol in your tests.