По мере развития продукта и его роста могут возникать различные сложности. В ходе работы над нашей системой MaxPatrol мы столкнулись с исчерпанием ресурсов команды, отвечающей за поддержку инфраструктуры проекта. В частности, нам требовалось наладить систему развертывания — с этим не все было просто. Сегодня мы расскажем о том, в чем конкретно были сложности, и как мы их преодолели, разработав собственный инструментарий для создания дистрибутивов.

Немного истории

В 2013 году инфраструктура нашего проекта выглядела следующим образом:

• 1 компонент продукта;
• 1 проект инсталлятора;
• 6 сервисов и конфигурационных файлов;
• 4 артефакта-источников файлов для дистрибутива;
• 1 человек из команды продукта занимался разработкой инсталлятора.

В процессе развития продукта он стал значительно более масштабным. Увеличивалось количество его обособленных компонентов, в каждом из них увеличивалось число пакетов инсталлятора, увеличивалась сложность каждого отдельного инсталлятора, становилось больше источников файлов. Стала необходимость создания специального отдела инфраструктуры продукта. Некоторые цифры на 2014-2015 год:

• 4 компонента продукта;
• 18 проектов инсталлятора;
• 20+ сервисов и конфигурационных файлов;
• 50+ артефактов;
• ~10 Feature Branches (FB) в одном релизе;
• 4 человека в новом отделе инфраструктуры продукта.

Все это приводило и к росту трудозатрат команды инфраструктуры — система становилась все сложнее, поэтому при внесении изменений необходимо было тратить время на то, чтобы понять, как правильно их осуществить. В результате среднее время ожидания внесения изменений увеличилось.

Мы тратили большое количество времени — каждое изменение необходимо было обсудить с заказчиком, приходилось разбираться с багами на этапе развертывания, далеко не все из которых были связаны с работой инсталлятора и т.д. При этом, изменения всегда имеют высокий приоритет, а значит — приходилось больше заниматься разгребанием этой «текучки», а не развитием инфраструктуры проекта.

В итоге сильно замедлилось развитие инфраструктурных аспектов таких как доставка обновлений, централизованное управление развертыванием и конфигурирование, инструментарий для создания инсталляционных пакетов.. Необходимо было что-то с этим делать.

Решение: разделение зон ответственности

Для оптимизации разработки мы решили разграничить зоны ответственности между членами команд развития инфраструктуры и развития продукта. Чтобы понять, как конкретно нужно это делать, мы провели анализ. Он позволил нам разбить все запросы на изменения на несколько групп:

• Изменение состава инсталлятора компонента — какие файлы из каких артефактов должны попасть в инсталлятор?
• Изменения настройки компонента — какие параметры должны настраиваться, а также в какие конфигурационные файлы и как должны прописываться параметры?
• Изменения требуемого состояния целевой операционной системы — какие сервисы, сайты, правила файрволла, задачи в планировщике, директории (и с какими правами) следует создать?

В итоге распределение различных задач довольно серьезно изменилось — от монопольного «владения» тремя этими классами вопросов командой инфраструктуры мы перешли к смешанной схеме:



Но мало просто договориться о разделении ответственности — нужно еще найти способ технически его реализовать.

DSL спешит на помощь

Domain-specific language или DSL — это такой язык, который подходит для использования в ходе работы над определенной задачей. Если говорить о нашем проекте, то с помощью DSL мы смогли «договориться» и получили инструмент, который позволил всем людям, причастным к разработке, решать свои задачи без необходимости глубоко вникать в детали продукта (как вносить изменения в конфигурационные файлы и т.п.) В итоге работа значительно ускоряется, а все сущности можно можно свободно расширять, что обеспечивает большую гибкость.

Вот какие технологии мы использовали на этом этапе:

• Python (Jinja2, PyYaml, jsonschema): генерация сценариев и конфигурационных файлов, валидация DSL-описаний, генерация документации по схеме;
• PowerShell: сценарии развертывания для Windows;
• C#: самописная библиотека функций для настройки Windows-окружения;
• WiX, MSI: создание инсталляционных пакетов для Windows.

Итоговая схема выглядела так: мы использовали DSL и шаблон сценария для генерации, собственно, итогового сценария.

Использование DSL (Yaml):



Описание сценария развертывания (Jinja2):



Получаем на выходе сценарий развертывания PowerShell:



Аналогичным образом отрабатывается создание конфигурационных файлов: сначала с помощью DSL описываются значения параметров, затем создается шаблон конфигурационного файла — на выходе получаем готовый «конфиг» с нужными параметрами.

Также идет работа и над генерацией документации — сначала разрабатывается схема DSL, потом создается HTML-шаблон документа, что позволяет на выходе получить готовую документацию в HTML.

Результаты и планы

Одним из главных достижений внедрения стал тот факт, что мы наконец-то получили адекватное распределение обязанностей между разработчиками и специалистами по инфраструктуре проекта.



Второй важный эффект: среди причастных к продукту людей перераспределились и знания. В частности, разработчики узнали больше о процессе развертывания — описания инсталлятора и шаблоны конфигураций находятся прямо в их проектах.

Также нам удалось значительно сократить время ожидания внесения изменений. Раньше процесс выглядел так:



В такой схеме мы приходили к постоянному снижению производительности из-за роста числа задач. Частично решить проблему можно было расширением отдела инфраструктуры, но у этого способа есть вполне очевидные рамки применимости. Да и задач всегда будет больше чем людей.

После внедрения новых подходов схема взаимодействия стала выглядеть так:



В результате время внесения изменений всегда одно и то же и не увеличивается от количества заказчиков, которым нужно решить определенную задачу.

Мы не собираемся останавливаться на достигнутом и планируем развивать нашу систему. Вот, что будет сделано уже в ближайшее время:

• Linux как еще одна целевая платформа — мы расширим DSL для описания специфичных для Linux сущностей ОС и реализуем поддержку.deb-сборки на основе описания состава пакета;
• Интеграция с SaltStack — шаблоны скриптов будут заменены на Salt States;
• Публикация инструментов на GitHub в открытом сообществе DevOpsHQ.

P. S. Рассказ о разработанном нами инструментарии для создания дистрибутивов был представлен в рамках DevOps-митапа, который состоялся недавно в Москве.



По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.

Автор: Владимир Селин