Как и зачем мы разработали свой инструмент для создания дистрибутивов продуктов



    По мере развития продукта и его роста могут возникать различные сложности. В ходе работы над нашей системой 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 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.

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

    P. P. S. Напоминаем, что совсем скоро при поддержке Positive Technologies в Москве пройдет курс по asyncio+aiohttp от Core-разработчика Python Андрея Светлова.

    Мы хотим предложить один бесплатный билет на семинар автору лучшего вопроса для Андрея — вопрос выберет он сам и ответит на него в ходе занятия. Присылайте свои вопросы по адресу: asyncio2016@ptsecurity.com.

    Comments 2

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

        Совсем не понятен вопрос — существующие системы чем не устроили? Скрипты/шаблоны есть если не у всех. то почти у всех.

        Only users with full accounts can post comments. Log in, please.