Настраиваем работу конвейера CI/CD (почти) без рук. Опыт использования Orchestra R в энтерпрайзе

Компании, что используют Jenkins в качестве CI/CD‑инструмента, обычно делают несколько экземпляров, если в разработке участвует множество команд или приходится работать с большим количеством проектов. При этом оркестрация Jenkins-ов в командах — не самая простая работа, а во многом ещё и рутинная. С одной стороны, сложно соблюдать все требования сборки и тестирования и вовремя находить согласующих. С другой, одним скриптом невозможно решить всю задачу от получения доступов до вывода релизов в эксплуатацию.

Есть правило, что если система становится слишком сложной, то люди чаще ищут способы обойти алгоритмы, а не следовать им. Чтобы не усложнять систему, а разложить всё по ролям и этапам, мы пришли к созданию собственного инструмента — Orchestra R. С его помощью мы хотели не только автоматизировать работу конвейера CI/CD, но и упростить жизнь всех DevOps‑инженеров. В этом материале поделимся особенностями работы инструмента и опытом эксплуатации в СберТехе.

Рождение музыки из духа трагедии

Есть несколько путей, чтобы упростить построение конвейера. Например, нанимать больше DevOps‑инженеров, чтобы каждый настраивал процесс под конкретную команду. Ещё можно построить один конвейер с сотнями шагов на все случаи жизни. Мы решили автоматизировать всё, что движется, а затем упаковать это в коробку с названием Orchestra R. Первая версия инструмента для внутреннего использования вышла ещё в 2017 году. В 2022 мы поняли, что достигли такой зрелости, что можем предложить решение рынку.

Наша бизнес‑задача строилась на том, что нужно сделать универсальный инструмент для сотен команд с разным производственным циклом. С одной стороны, решение здесь максимально простое — шаблонизация и использование предварительно настроенных компонентов. С другой, важно было правильно определить порядок вывода новых фич, учесть всё многообразие продуктов банка и привести пользовательские сценарии к общему UX‑знаменателю.

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

Прежде всего мы хотели закрыть проблему с ручным согласованием, которое задерживало производственный цикл многих команд. Затем внедрили Quality Gates и систему флагов, по которым определяли обязательные условия готовности сборок. Другая важная цель, которую мы преследовали — сократить потери времени на переключение между окнами и задачами.

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

Наш конвейер проходит этапы слева направо и сверху вниз. Если он доходит до запуска ручного действия, то просто встаёт в очередь и ожидает согласования от группы. При этом есть возможность (включается по галочке) указывать только параметры, а время запуска планируется пользователем.

Почему это удобно

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

Снижается порог входа. Если сказать: «Запусти мне эту джобу», то нужно сначала понять, как её параметризовать. В Orchestra R этот процесс упрощён и происходит в режиме low‑code настройки блоков конвейера. Параметры хранятся внутри продукта, есть подготовленные скрипты — достаточно выбрать необходимый из списка. Даже начинающие специалисты смогут настроить сложные конвейеры.

Упрощение кода. Это достигается с помощью дробления на атомарные операции. DevOps‑инженерам не приходится кодом описывать сложные логические конструкции, тем самым минимизируя ошибки.

Прозрачность. В рамках одного конвейера можно настроить обращения к любому количеству Jenkins, находящихся в сегментах сети.

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

Как работает Orchestra R

Сейчас мы пришли к тому, что один DevOps‑инженер может настроить конвейер для всех команд. Процесс почти полностью автоматизирован, минимальное вмешательство специалистов потребуется, если упадёт какой‑то этап: можно будет зайти и посмотреть, что случилось.

Занимательные флаги

Каждый кубик в визуальном редакторе — отдельный этап. Чтобы выйти в прод, потребуется выполнить одно или несколько таких действий, запустив необходимые скрипты. Нужно добавить флаги и их проверку: если не соответствует ожиданиям, то пропускаем. Так мы исключаем случайное развёртывание и баним релизы, которые не соответствуют своему циклу проверок. Сущность флага — контроль соответствия заложенной проверке. Например, есть флаг, фиксирующий результат прохождения нагрузочных тестов. Можно добавлять разные условия на каждый этап, настроить Quality Gate — проверить до или после запуска.

Мы, на всякий случай, не исключаем, что кто‑то захочет провести релиз без тестов. Проверки соответствия могут быть проконтролированы как дополнительная страховка от мошенничества. В реализованном процессе тесты должны пройти, например, через Quality Gate Manager, который контролирует флаги. Если команда самостоятельно установила флаг соответствия «без проверок», то дистрибутив не пройдёт дальше.

Можно назначать проверки обязательные, опциональные или по условию. Пользователь может внести данные о своих переменных. Например, если у флага не будет определённого значения (всё, кроме ОК), то конвейер дальше не идет.

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

Кроме этого есть возможность обработки хуков. Если, например, в Nexus добавилась новая сборка, то на неё можно сразу завязать автоматизацию. Если в Bitbucket появился новый код, то можно привязать сервис к конкретному репозиторию. Как только там появляется код — запускаем триггерные действия.

Шаблонизация

Наш инструмент позволяет создавать шаблоны этапов и конвейеров, которые потом могут быть использованы любыми командами. Это помогает ускорить настройку конвейера в десятки раз и создавать их без написания кода. При поставке продукта мы даём ряд готовых шаблонов, но пользователи также могут разрабатывать и добавлять новые шаблоны самостоятельно, чтобы адаптировать их под свой процесс разработки.

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

Особенности настройки конвейера

Если хочется дополнить шаблонный конвейер вручную, это тоже делается в режиме low‑code. Мы можем перенести этапы с нужными названиями и добавить им действия. В настройках достаточно добавить переменную, указать ключ и значение, которое можно выбрать из справочника. Далее URL будет достаточно вставить в нужное поле.

В ручных фазах участникам процесса можно ставить разные задачи в системах, которые не интегрированы в DevOps‑конвейер напрямую. Например, у нас запущен конвейер, а нам нужно переложить документацию из релизной ветки в мастер. Мы можем вставить этот блок в текущий процесс (он может быть обязательным или нет), что позволяет вокруг DevOps‑конвейера строить ещё и BPM.

Эти действия запускаются следующим образом: все фазы, что находятся на одной горизонтальной прямой, стартуют одновременно (при соответствии условий запуска). Когда все обязательные «горизонтальные» действия будут выполнены, запустятся следующие фазы. Можно настраивать функциональные шаги, чтобы их результаты не влияли на остальное. Например, скрипт выполнения нагрузочных долговременных тестов работает 10 часов, но мы можем выполнять параллельные действия в конвейере.

Есть сервисные фазы, которые нужны, чтобы предоставлять командам возможность выполнять определённые типизированные шаги с минимальными усилиями. Например, чтобы запустить обычную Jenkins‑фазу приходится указывать ПО, ссылку, логин, токен для запуска и параметры. А для сервисной фазы установки Quality Gate этого делать не требуется. Сервисные фазы используют в разной степени все команды, поэтому мы реализовали нативную настройку в пару кликов.

Как настройка выглядит с точки зрения процесса

В корневой папке лежат проекты. К ним имеет доступ владелец и команда (например, мобильное приложение банка). Внутри проекта есть набор версий для iOS или Android. Приложения по моделям операционных систем разложены по папкам.

Каждый прямоугольник — микросервис, который можно отдельно собрать, проверить связку с остальными и вывести в прод. Команды, которые работают внутри приложения, могут не знать о своих соседях, о настройках, с которыми они работают, поскольку работа полностью изолируется. Такая иерархия позволяет создать конвейер на уровне проекта, приложения или сервиса (один или более) и масштабировать его. Если мы создаём на уровне проекта конвейер, то он автоматически становится доступным для всех входящих в него приложений. Когда DevOps‑инженер на уровне проекта выполняет действие, все настройки автоматически будут выданы на уровень этого приложения.

Если что‑то отличается на уровне конкретного приложения, то на его уровне делаем или отдельный конвейер (тогда его сервисы смогут им пользоваться), либо переопределяем настройки. Конфиденциальные настройки вроде «ответственный» и «параметры» можно не сохранять. Мы как бы используем болванку конвейера, но на уровне приложения можем поменять группы ответственных и переопределить параметры (URL, стенды), что обеспечивает гибкость работы.

Заключение

Пожалуй, в полной мере инструмент раскрывается в крупных компаниях, а также в тех, где есть внутренний портал, сайт, мобильное приложение — целый список сущностей, которые нужно поддерживать разным командам. Например, в e‑com обычно есть приложение для клиентов, для курьеров, есть веб‑версия магазина и внутренние порталы. Когда сотни команд получают возможность автоматизировать рутинные операции и настраивать сложные конвейеры за 1 час вместо пары дней, в масштабах организации это имеет значительный эффект. В конвейерах из 3–5 шагов, когда нет «конкуренции» с другими командами за релизное время, — улучшение, возможно, не так заметно.

При разработке Orchestra R мы ориентировались, прежде всего, на внутренние потребности распределённых команд и всё многообразие их производственных циклов. Инструмент информативен, поэтому каждый может быстро получить данные по своей области ответственности. Определить этап, на котором находится сборка, или отследить ошибку по журналам. Большое значение здесь играет визуализация, которая позволяет не тратить время на путешествия по Jenkins. Другое важное преимущество — возможность рациональнее использовать ценных DevOps‑инженеров, а не тратить порядка 70 % рабочего времени на очередную настройку конвейера. Для этого используются шаблоны, которыми может оперировать даже ИТ‑специалист без опыта и глубоких знаний DevOps‑практик. Подробнее ознакомиться с функциональностью Orchestra R можно, записавшись на демо.