Ivan Kolodyazhny "A very short introduction to Kubernetes Operators developme...Fwdays
Kubernetes is almost everywhere. Complicated application deployments could be handled by Kubernetes Operators.
During the talk, I'll give you a brief introduction of how to implement own K8S operators with Python using Kopf framework based on a real-world example.
Ivan Kolodyazhny "A very short introduction to Kubernetes Operators developme...Fwdays
Kubernetes is almost everywhere. Complicated application deployments could be handled by Kubernetes Operators.
During the talk, I'll give you a brief introduction of how to implement own K8S operators with Python using Kopf framework based on a real-world example.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Traditional virtualization technologies have been used by cloud infrastructure providers for many years in providing isolated environments for hosting applications. These technologies make use of full-blown operating system images for creating virtual machines (VMs). According to this architecture, each VM needs its own guest operating system to run application processes. More recently, with the introduction of the Docker project, the Linux Container (LXC) virtualization technology became popular and attracted the attention. Unlike VMs, containers do not need a dedicated guest operating system for providing OS-level isolation, rather they can provide the same level of isolation on top of a single operating system instance.
An enterprise application may need to run a server cluster to handle high request volumes. Running an entire server cluster on Docker containers, on a single Docker host could introduce the risk of single point of failure. Google started a project called Kubernetes to solve this problem. Kubernetes provides a cluster of Docker hosts for managing Docker containers in a clustered environment. It provides an API on top of Docker API for managing docker containers on multiple Docker hosts with many more features.
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.
"Building data streams" Константин Евтеев (Avito)AvitoTech
С ростом объема данных, количества пользователей и, как следствие, ростом нагрузки, возникает вопрос о масштабируемой архитектуре и распределении нагрузки, сохраняя при этом консистентность данных и отказоустойчивость системы. В своем докладе я расскажу, как мы решаем эти вопросы в Avito. Речь пойдет о реализации отдельных компонентов мета-шаблона Lambda Architecture с помощью PGQ и Londiste:
1. Работа с разными моделями данных: для обновления и чтения информации.
2. Batch and stream processing, обрабатывающий 1000 событий в секунду.
3. Инициализация и поддержка remote aggregates data sources.
4. Сохранение консистентности данных.
5. Восстановление при авариях и др.
До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в Microsoft SQL Server. Многие знают, что для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.
Это ограничение подвело нас к необходимости использования NewSQL хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного (сразу приходит на ум только Google Spanner), а доступных — и вовсе нет. Поэтому мы реализовали такую систему сами на любимой нами Java и запустили ее в промышленную эксплуатацию несколько месяцев назад.
Доклад про то, как устроено это хранилище будет интересен всем, кто следит за развитием технологий управления базами данных и имеет опыт работы с (No)SQL.
Kubernetes Helm (Boulder Kubernetes Meetup, June 2016)Matt Butcher
Kubernetes Helm is the package manager for Kubernetes. In this presentation, we walk through the basics of Helm, Tiller, and the Helm Charts file format.
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Traditional virtualization technologies have been used by cloud infrastructure providers for many years in providing isolated environments for hosting applications. These technologies make use of full-blown operating system images for creating virtual machines (VMs). According to this architecture, each VM needs its own guest operating system to run application processes. More recently, with the introduction of the Docker project, the Linux Container (LXC) virtualization technology became popular and attracted the attention. Unlike VMs, containers do not need a dedicated guest operating system for providing OS-level isolation, rather they can provide the same level of isolation on top of a single operating system instance.
An enterprise application may need to run a server cluster to handle high request volumes. Running an entire server cluster on Docker containers, on a single Docker host could introduce the risk of single point of failure. Google started a project called Kubernetes to solve this problem. Kubernetes provides a cluster of Docker hosts for managing Docker containers in a clustered environment. It provides an API on top of Docker API for managing docker containers on multiple Docker hosts with many more features.
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.
"Building data streams" Константин Евтеев (Avito)AvitoTech
С ростом объема данных, количества пользователей и, как следствие, ростом нагрузки, возникает вопрос о масштабируемой архитектуре и распределении нагрузки, сохраняя при этом консистентность данных и отказоустойчивость системы. В своем докладе я расскажу, как мы решаем эти вопросы в Avito. Речь пойдет о реализации отдельных компонентов мета-шаблона Lambda Architecture с помощью PGQ и Londiste:
1. Работа с разными моделями данных: для обновления и чтения информации.
2. Batch and stream processing, обрабатывающий 1000 событий в секунду.
3. Инициализация и поддержка remote aggregates data sources.
4. Сохранение консистентности данных.
5. Восстановление при авариях и др.
До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в Microsoft SQL Server. Многие знают, что для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.
Это ограничение подвело нас к необходимости использования NewSQL хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного (сразу приходит на ум только Google Spanner), а доступных — и вовсе нет. Поэтому мы реализовали такую систему сами на любимой нами Java и запустили ее в промышленную эксплуатацию несколько месяцев назад.
Доклад про то, как устроено это хранилище будет интересен всем, кто следит за развитием технологий управления базами данных и имеет опыт работы с (No)SQL.
Kubernetes Helm (Boulder Kubernetes Meetup, June 2016)Matt Butcher
Kubernetes Helm is the package manager for Kubernetes. In this presentation, we walk through the basics of Helm, Tiller, and the Helm Charts file format.
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
Предложение МКД Партнер в области ОценкиМКД Партнер
АО «МКД Партнёр» осуществляет профессиональную деятельность по оценке стоимости материальных и нематериальных объектов с учётом прав на них и интересов в отношении них субъектов гражданских прав
ЦЕЛИ ОЦЕНКИ
- Привлечение заемного финансирования
- Принятие управленческих решений
- Переоценка основных фондов
- Для целей взноса в уставной капитал
- Для целей МСФО
- Оформление наследства
- Имущественные споры
- Страхование
- Купля-продажа и др.
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Сегментация изображений на острие науки (Евгений Нижибицкий, Rambler&Co)AvitoTech
В последнее время на популярных площадках появляется все больше конкурсов, связанных с компьютерным зрением, и в особенности — с сегментацией изображений. Некоторое время назад в таких задачах повсеместно доминировали подходы на основе сети U-Net. Евгений расскажет о решениях двух недавно завершившихся конкурсов, где хорошо зарекомендовали себя подходы на основе новой, претендующей на “народное признание“, сети.
Применение компьютерного зрения для анализа спортивных соревнований (Николай ...AvitoTech
Большое количество статистической информации о ходе спортивных игр и соревнований собирается вручную. Для автоматизации этого процесса можно использовать методы компьютерного зрения. В докладе будут рассмотрены подходы к анализу видеопотока с игры в настольньй теннис в реальном времени. Будут предложены алгоритмы, основанные на искусственных нейронных сетях и классическом компьютерном зрении для определения игровых событий, траектории мяча и фиксации результатов с судейского табло, а также представлены первые результаты.
Распознавание лиц с помощью глубоких нейронных сетей (Сергей Миляев, VisionLabs)AvitoTech
В докладе будут рассмотрены основные научные работы, которые позволили нейронным сетям распознавать людей точнее, чем это делает человек. Также будут продемонстрированы результаты компании VisionLabs на независимых международных тестах Face Recognition Vendor Test института NIST и Labeled Faces in the Wild Университета Массачусетса.
AvitoNet: сервис компьютерного зрения в Avito (Артур Кузин, Avito)AvitoTech
В Avito активно используется машинное обучение в различных микросервисах и продуктах. В докладе будет рассказано про часть, связанную с компьютерным зрением: AvitoNet. Это внутренний датасет и обученные на нём нейросети. Артур Кузин расскажет про задачи, которые ставились перед сервисом AvitoNet на этапе планирования, а также о выбранном подходе к решению и эволюции сервиса. Будут показаны результаты с демонстрацией работы AvitoNet во время подачи объявлений.
Добиваемся эффективности каждого из 9000+ UI-тестов - Максим Сахаров (Tutu.ru)AvitoTech
Любой проект со временем растет и наполняется новыми функциональными возможностями. QA-процессы должны оперативно и адекватно на это реагировать. Например, увеличением количества тестов всех видов. В этом докладе мы будем говорить про UI-тесты, которые играют важную роль в создании качественного продукта.
Количество тестов постепенно растет: от 1000 к 3000, от 6000 к 9000+ и т.д. Чтобы эта лавина не "накрыла" наш QA-процесс, нужно с самого раннего этапа развития проекта автоматизации думать про эффективность всей системы и каждого теста в ней.
В этом докладе я расскажу, как сделать систему гибкой к изменениям, а также про эффективное использование каждого из тестов. Кроме того, мы поговорим про оценку и метрики не только процессов автоматизации, но и всего QA.
Avito Automation Meetup (26.08.2017)
https://avitotech.timepad.ru/event/542380/
Проблемы управления тестами, или Что мешает создавать дешевые и полезные тест...AvitoTech
Мы все стремимся создавать качественные продукты. Мы знаем, что для того, чтобы создавать качественные тесты, их надо проверять, а значит, создавать тесты. Мы все знаем насколько это нужно… до того момента, пока не начинаем делать продукт.
И как только мы с горящими глазами садимся создавать свои тесты, нам тут же начинает мешать множество вещей: долго, дорого, ненужно, неэффективно… Хотя вот буквально пару недель назад все были согласны, что нужно писать тесты.
Давайте посмотрим, можно ли выбраться из этого лабиринта отговорок и создавать тесты быстро, дёшево и эффективно их потом поддерживать.
Avito Automation Meetup (26.08.2017)
https://avitotech.timepad.ru/event/542380/
Запускаем тесты в Continuous Integration - Сергей Пак (JetBrains)AvitoTech
Continuous integration умеет запускать тесты. Для этого его и придумали. Однако, как всегда, есть нюансы, связанные с теми или иными видами тестов. На митапе я расскажу про особенности настройки CI для работы с нагрузочным, приёмочным, интеграционным, UI- и Smoke-тестированием, проверкой корректности установки и апгрейда. Поговорим о том, на какие грабли можно при этом наступить и как их обойти.
Avito Automation Meetup (26.08.2017)
https://avitotech.timepad.ru/event/542380/
Векторы развития систем автоматизации тестирования - Дмитрий Химион (Avito)AvitoTech
Вы думаете, что сделали все для того, чтобы ваша система автоматизации тестирования работала чётко и правильно? Закрыли список задач? Или наоборот, находитесь в поиске того, что еще не охвачено? Тогда этот доклад для вас и для всех, кто интересуется автоматизацией тестирования и её гранями.
Когда все процессы в системах автотестирования работают нормально и выдают релевантные результаты, есть риск обмануться, что сделано уже всё, впереди — лишь унылая актуализация автотестов. Доклад прольет свет на то, что можно делать полезного в рамках и вокруг автоматизации тестирования.
Avito Automation Meetup (26.08.2017)
https://avitotech.timepad.ru/event/542380/
Прокачиваем WebDriverAgent, или Как тестировать iOS-приложения после ядерного...AvitoTech
Когда в прошлом году Apple с выходом Xcode 8 отказались от UI Automator, мы, как и многие, оказались у разбитого корыта. Appium, который у нас использовался, потерял актуальность, мы начали искать альтернативы и нашли инструмент WebDriverAgent от Facebook. Доклад о том, с какими проблемами мы столкнулись, как мы их решали и как это повлияло на нашу инфраструктуру тестирования iOS-приложений.
Avito Automation Meetup (26.08.2017)
https://avitotech.timepad.ru/event/542380/
3. Центр Недвижимости от Сбербанка
u Первый сервис для приобретения
недвижимости в ипотеку.
u Онлайн подача заявки на ипотеку из
офиса агентства или застройщика
u Онлайн подача заявок в Росреестр на
регистрацию права собственности.
u Управление офисными и полевыми
активностями сотрудников Банка.
u Система проверки объекта
недвижимости и всех участников
сделки
2
5. План
1. Начало нашей компании
2. Как мы развивались
3. Когда пришло время что то менять
4. Выбор решения
5. Обзор нашей работы с Kubernetes
6. Заключение
4
6. Спустя год существования
компании
u Более 10 работающих сервисов
u Около 10 сервисов в разработке
u Языки программирования - Java, PHP,
Python
u Docker
u Dev, QA, Stage, Prod
u Мониторинг
5
11. Плюсы Kubernetes
u Встроенный механизм деплоя
u Встроенный автоскейлинг
u Полностью готовая внутренняя
инфраструктура
u Опенсорс
u Комюнити
u Наличие пакетного менеджера
10
15. Перевод приложений в
Kubernetes
1. Заказ на перевод приложения
2. Описание необходимых абстракций
3. Темплейтирование в Helm
4. Написание пайплайна
5. Разворачивание QA, Stage
6. Тестирование
7. Вывод в Prod
14
16. Планы на будущее
u Развертывание стендов тестирования в
Kubernetes по кнопке в Jira
u Система распределенной
трассировки
u Система автоматизированной
проверки контейнеров на уязвимости
15