Как мы собираем проекты в выделенном окружении в Windows DockerPositive Hack Days
1. Обзор Windows Docker (кратко)
2. Как мы построили систему билда приложений в Docker (Visual Studio\Mongo\Posgresql\etc)
3. Примеры Dockerfile (выложенные на github)
4. Отличия процессов DockerWindows от DockerLinux (Долгий билд, баги, remote-регистр.)
Типовая сборка и деплой продуктов в Positive TechnologiesPositive Hack Days
1. Проблемы в построении CI процессов в компании
2. Структура типовой сборки
3. Пример реализации типовой сборки
4. Плюсы и минусы от использования типовой сборки
Инструмент ChangelogBuilder для автоматической подготовки Release NotesPositive Hack Days
1. Основные понятия и определения: продукт, пакет, связи между ними.
2. Как узнать, какие изменения произошли в продукте?
3. Проблемы changelog и release note.
4. Решение: инструмент ChangelogBuilder для автоматической подготовки Release Notes
Как мы собираем проекты в выделенном окружении в Windows DockerPositive Hack Days
1. Обзор Windows Docker (кратко)
2. Как мы построили систему билда приложений в Docker (Visual Studio\Mongo\Posgresql\etc)
3. Примеры Dockerfile (выложенные на github)
4. Отличия процессов DockerWindows от DockerLinux (Долгий билд, баги, remote-регистр.)
Типовая сборка и деплой продуктов в Positive TechnologiesPositive Hack Days
1. Проблемы в построении CI процессов в компании
2. Структура типовой сборки
3. Пример реализации типовой сборки
4. Плюсы и минусы от использования типовой сборки
Инструмент ChangelogBuilder для автоматической подготовки Release NotesPositive Hack Days
1. Основные понятия и определения: продукт, пакет, связи между ними.
2. Как узнать, какие изменения произошли в продукте?
3. Проблемы changelog и release note.
4. Решение: инструмент ChangelogBuilder для автоматической подготовки Release Notes
1. Что такое BI. Зачем он нужен.
2. Что такое Qlik View / Sense
3. Способ интеграции. Как это работает.
4. Метрики, KPI, планирование ресурсов команд, ретроспектива релиза продукта, тренды.
5. Подключение внешних источников данных (Excel, БД СКУД, переговорные комнаты).
Codeception + Docker + Robo и что из этого вышлоCOMAQA.BY
Параллелизация тестов, а именно: лучший пхп тулл для автоматизации (Codeception); основы Docker контейнирезации; robo - что это и зачем он нам нужен; profit
В своем докладе я поделюсь опытом использования сервера непрерывной интеграции Jenkins, который мы подняли для справочного и картографического API и проекта Онлайн.
Сделаю упор на следующих моментах:
— Jenkins — быстрый старт, как за час сделать свой первый билд.
— Возможности Jenkins: сборка проекта из репозитория, запуск тестов, создание отчётов.
— Расширение функционала: Pipeline (упорядочение сборок), Violations (красивая статистика), E-mail-плагин, плагин от Чака Нориса и пр.
— Опыт использования в веб-проектах 2ГИС.
Пакетный менеджер CrossPM: упрощаем сложные зависимости | Александр КовалевPositive Hack Days
1. Сложности при распутывании перекрёстных и вложенных зависимостей.
2. Пакетный менеджер CrossPM. Его возможности и примеры использования.
3. Интеграция CrossPM и системы хранения пакетов Artifactory.
Мифы о DevOps / Александр Титов, Иван Евтухович (Экспресс 42)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 10:00
Тезисы:
http://rootconf.ru/2017/abstracts/2830.html
Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.
Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
...
Практически все известные мне передовые проекты используют Agile, как способ быстрой разработки ПО. За счет чего обеспечивается быстрая разработка? Правильно, множеством процессов, один из которых «автоматизация тестирования ПО».
Хорошо когда у вас есть время выработать фреймфорк, который хорошо ложиться в ваш проект. Но когда времени нет, то надо двигаться быстро. Зачастую выбор падает в сторону уже существующих фреймворков, с помощью которых можно быстро выполнить необходимую автоматизацию и максимально решить ваши задачи.
RobotFramework – это фреймворк высокого уровня, с помощью которого можно строить keyword-driven, data-driven и acceptance авто-тесты. В своем докладе я расскажу, что такое RobotFramework, где он используется и как его можно применить.
Изучай python и автоматизацию на тестирования на python на http://lessons2.ru
Prometheus мониторинг микросервисных приложений / Виталий ЛевченкоOntico
Prometheus, в отличие от классических систем, даёт возможность легко поднять и поддерживать мониторинг быстро меняющихся и сложно организованных систем. Я расскажу об опыте внедрения, подводных камнях и неожиданном поведении, покажу способы быстрой конфигурации всей системы, включая уведомления и дашборды.
В дополнение к классическим проблемам мониторинга монолитного приложения, микросервисы создают массу новой головной боли для мониторинга. Расположение сервисов постоянно меняется, часто появляются новые сервисы, меняются зависимости между ними, временные job'ы запускаются в случайном месте — пропадает понятие стабильной конфигурации. Пропадает понятие продакшна: в одной среде запущено множество версий одного сервиса — при деплое, для разных сегментов аудитории, для тестов и т.п. Разработчики же при виде такого счастья склонны быстро улучшать приложение, создавать много новых метрик, постоянно убивать старые и, несмотря на это, ожидать работающий мониторинг и реакции на новые проблемы.
Prometheus построен по мотивам Google Borgmon и отлично решает эти проблемы, предоставляя инструменты для автоматического и быстрого ручного обновления конфигурации. Запустился новый сервер, новый сервис, новая версия — и они уже подключены в мониторинг. Остановились — их там нет, если не нужны. Пропала неактуальная метрика — алертинг умеет с этим жить.
После этого доклада у вас будет понимание, насколько Prometheus подходит для использования в ваших системах.
Непрерывная интеграция Python-проектов в ЯндексеAndrey Kazarinov
Рутинные операции тестирования, сборки и развёртывания заставляют в нервном ожидании толстеть на кофепоинте, а частый релизный цикл создаёт лёгкое головокружение? Чтобы помочь вам сохранить тело подтянутым, а голову светлой, я расскажу об организации и особенностях непрерывной интеграции в Python-проектах на примере популярных инструментов.
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
1. Что такое BI. Зачем он нужен.
2. Что такое Qlik View / Sense
3. Способ интеграции. Как это работает.
4. Метрики, KPI, планирование ресурсов команд, ретроспектива релиза продукта, тренды.
5. Подключение внешних источников данных (Excel, БД СКУД, переговорные комнаты).
Codeception + Docker + Robo и что из этого вышлоCOMAQA.BY
Параллелизация тестов, а именно: лучший пхп тулл для автоматизации (Codeception); основы Docker контейнирезации; robo - что это и зачем он нам нужен; profit
В своем докладе я поделюсь опытом использования сервера непрерывной интеграции Jenkins, который мы подняли для справочного и картографического API и проекта Онлайн.
Сделаю упор на следующих моментах:
— Jenkins — быстрый старт, как за час сделать свой первый билд.
— Возможности Jenkins: сборка проекта из репозитория, запуск тестов, создание отчётов.
— Расширение функционала: Pipeline (упорядочение сборок), Violations (красивая статистика), E-mail-плагин, плагин от Чака Нориса и пр.
— Опыт использования в веб-проектах 2ГИС.
Пакетный менеджер CrossPM: упрощаем сложные зависимости | Александр КовалевPositive Hack Days
1. Сложности при распутывании перекрёстных и вложенных зависимостей.
2. Пакетный менеджер CrossPM. Его возможности и примеры использования.
3. Интеграция CrossPM и системы хранения пакетов Artifactory.
Мифы о DevOps / Александр Титов, Иван Евтухович (Экспресс 42)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 10:00
Тезисы:
http://rootconf.ru/2017/abstracts/2830.html
Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.
Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
...
Практически все известные мне передовые проекты используют Agile, как способ быстрой разработки ПО. За счет чего обеспечивается быстрая разработка? Правильно, множеством процессов, один из которых «автоматизация тестирования ПО».
Хорошо когда у вас есть время выработать фреймфорк, который хорошо ложиться в ваш проект. Но когда времени нет, то надо двигаться быстро. Зачастую выбор падает в сторону уже существующих фреймворков, с помощью которых можно быстро выполнить необходимую автоматизацию и максимально решить ваши задачи.
RobotFramework – это фреймворк высокого уровня, с помощью которого можно строить keyword-driven, data-driven и acceptance авто-тесты. В своем докладе я расскажу, что такое RobotFramework, где он используется и как его можно применить.
Изучай python и автоматизацию на тестирования на python на http://lessons2.ru
Prometheus мониторинг микросервисных приложений / Виталий ЛевченкоOntico
Prometheus, в отличие от классических систем, даёт возможность легко поднять и поддерживать мониторинг быстро меняющихся и сложно организованных систем. Я расскажу об опыте внедрения, подводных камнях и неожиданном поведении, покажу способы быстрой конфигурации всей системы, включая уведомления и дашборды.
В дополнение к классическим проблемам мониторинга монолитного приложения, микросервисы создают массу новой головной боли для мониторинга. Расположение сервисов постоянно меняется, часто появляются новые сервисы, меняются зависимости между ними, временные job'ы запускаются в случайном месте — пропадает понятие стабильной конфигурации. Пропадает понятие продакшна: в одной среде запущено множество версий одного сервиса — при деплое, для разных сегментов аудитории, для тестов и т.п. Разработчики же при виде такого счастья склонны быстро улучшать приложение, создавать много новых метрик, постоянно убивать старые и, несмотря на это, ожидать работающий мониторинг и реакции на новые проблемы.
Prometheus построен по мотивам Google Borgmon и отлично решает эти проблемы, предоставляя инструменты для автоматического и быстрого ручного обновления конфигурации. Запустился новый сервер, новый сервис, новая версия — и они уже подключены в мониторинг. Остановились — их там нет, если не нужны. Пропала неактуальная метрика — алертинг умеет с этим жить.
После этого доклада у вас будет понимание, насколько Prometheus подходит для использования в ваших системах.
Непрерывная интеграция Python-проектов в ЯндексеAndrey Kazarinov
Рутинные операции тестирования, сборки и развёртывания заставляют в нервном ожидании толстеть на кофепоинте, а частый релизный цикл создаёт лёгкое головокружение? Чтобы помочь вам сохранить тело подтянутым, а голову светлой, я расскажу об организации и особенностях непрерывной интеграции в Python-проектах на примере популярных инструментов.
Леонид Васильев "Python в инфраструктуре поиска"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Леонид Васильев "Python в инфраструктуре поиска"
О докладе:
Описание архитектуры и реализации внутренних инструментов для управления поисковым кластером.
Что такое инфраструктура поиска? Какие задачи приходится решать? Какие инструменты для управления кластером используются в поиске? Как они устроены изнутри? Что можно посоветовать проектам с большой инфраструктурой? Какие существуют open-source аналоги?
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Приемы Сontinuous Integration при разработке приложений на CachéInterSystems CEE
Об организации автоматизированного рабочего процесса в InterSystems Caché, Лебедюк /
Implementing modern developement practices with InterSystems Caché, Eduard Lebedyuk
Approach on how make Continuous Integration development cycle with InterSystems Caché.
Caché Object Script solution for CI with Github
https://github.com/intersystems-ru/CacheGitHubCI
Open Source Testing Framework: real project example and best practicesAliaksandr Ikhelis
Summary: Presentation on open source testing frameworks (improved version, more focus on real project example) at Software Engineering Forum 2009 (SEF-1) conference by Aliaksandr Ikhelis. Sponte framework developer and owner is Stanislaw Wozniak, Expedia Limited, UK. Sponte project homepage: http://rubyforge.org/projects/sponte/; http://github.com/swozniak/sponte/tree/master
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
Legacy в коробочке. Dev-среда на базе Kubernetes / Илья Сауленко (Avito)Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 15:00
Тезисы:
http://ritfest.ru/2017/abstracts/2653.html
Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
6. 〉Частые релизы (2-3 раза в неделю) + хотфиксы
〉До 10 одновременных разработчиков проекта
〉Много подпроектов, микросервисов, библиотек, пакетов (>20)
〉Много зависимостей, включая бинарные (>10)
〉Debian-пакеты
6
Условия разработки
7. 〉Несколько окружений (development, testing, prestable, production)
〉Большое количество серверов (от 3-х до нескольких сотен)
〉Разные платформы Ubuntu (lucid, precise, trusty)
〉Необходимость переживать учения (N-1 датацентр)
7
Условия эксплуатации
8. 〉N-1 датацентр
〉Плановые – замена сетевого оборудования
〉Внеплановые – бешеный экскаваторщик, котик в подстанции
〉Периодически
8
Учения
Подробнее: Как и для чего Яндекс отключает собственные дата-центры – https://clck.ru/9aWTK
Сервис без downtime и желательно без read-only
11. 〉«Собираем всех в одно гнездо» – все разработчики и проекты
разрабатываются на одной dev-машине
〉«Virtualenv в каждый дом»
〉«Береги код смолоду» (pep8, flake8, … )
〉«Trust but check»
11
Наши принципы
13. 〉Микросервисы
〉Frontend + Backend API
〉HTTP/HTTPS, решительное нет CORBA
〉from XML to JSON
〉Infrastructure as a Service (OpenStack)
〉PaaS хостинг приложение (Cocaine)
13
Архитектурные принципы
16. 〉Unit-тесты пишутся разработчиками (unittest2, nose, pytest)
〉Code coverage (в среднем 70-80%, >10к тестов в одном из проектов)
〉Моки внешних сервисов
〉Часто запускаются разработчиками
〉Прогоняются при сборке
16
Unit-тесты
17. 〉Пишутся тестировщиками
〉Автоматизируем там, где это возможно
〉Ansible – тестовые сценарии
〉HTML Elements – тестирование интерфейсов
〉Allure Framework – построение отчетов
〉Запускаются тестировщиками перед релизом
17
Функциональное тестирование
18. 〉Оценка производительности для расчета количества серверов
〉Сравнение различных технологических решений
〉Выявление скрытых багов, проявляющихся под нагрузкой
〉Периодическая регрессионная проверка производительности
18
Нагрузочное тестирование
19. 〉Яндекс.Танк
мониторинг ресурсов
интерфейс для вывода графиков и управления «стрельбой»
модульность
различные профили нагрузки
поддержка различных протоколов (HTTP/SMTP/POP3/FTP/DNS)
〉«Стрельба» ведется на отдельном нагрузочном стенде
〉«Мишень» –микросервис или отдельный функционал сервиса
〉«Патроны» – подготовленные HTTP запросы
19
Яндекс.Танк
Подробнее: Яндекс.Танк – https://tech.yandex.ru/tank/
26. 〉Созданное окружение в pbuilder уничтожается
〉Прокидываем директории для кэша из системы при инициализации
образа
.pbuilderrc
BINDMOUNTS=<path to cache>
HOOKDIR=<path to hooks>
26
Хитрости кэширование Python Wheels
Подробнее: Pip install – почему так медленно? https://clck.ru/9ab2b
31. 〉Каждое изменение должно интегрироваться
〉Тесты
〉Быстрая сборка (<10 минут)
〉Интеграция на выделенной машине
31
Принципы непрерывной интеграции
32. 〉TeamCity
〉Агенты для проекта и есть общий пул агентов
〉Шаблоны сборок
〉Интеграция с GitHub
〉Conductor – установка пакета на сервера (внутренний продукт)
32
Система непрерывной интеграции
Подробнее: Непрерывная интеграция Python-проектов в Яндексе – https://clck.ru/9aWTZ
41. 1. Сборка пакета
1. Создание изолированного окружения
2. Сборка virtualenv с тестовыми утилитами
3. Тестирование с coverage
4. Сборка продакшен virtualenv
2. Публикация результатов coverage в GitHub (в pull request)
3. Загрузка debian-пакета на внутренний debian-репозиторий
4. Загрузка python-пакета на внутренний PyPI (в случае библиотеки)
5. Тикет в систему деплоймента пакетов (Conductor)
41
Шаги
47. 〉Выявление багов на раннем этапе – дешевле разработка
〉Частые релизы – ускоренный feedback
〉Аккуратный однотипный код – легче поддерживать
47
Для менеджеров
48. 〉На одной машине могут стоять пакеты с зависимостями различных
версий (virtualenv)
〉Пакет собирается в окружении близком к production (pbuilder)
〉Легко создавать новые сборки (унифицикация сборок, шаблоны)
〉Быстрая сборка пакета (до 10 минут) (кэширования Python Wheels)
48
Для разработчиков
51. 〉Контроль за стилем кода – https://events.yandex.ru/lib/talks/2444/
〉Как и для чего Яндекс отключает собственные дата-центры –
http://habrahabr.ru/company/yandex/blog/243033/
〉Pip install – почему так медленно? https://events.yandex.ru/lib/talks/3070/
〉Непрерывная интеграция Python-проектов в Яндексе –
https://events.yandex.ru/lib/talks/3071/
51
Источники