Як і навіщо ми розробили свій інструмент для створення дистрибутивів продуктів



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

Автор: Володимир Селін
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.