Какие инструменты первыми приходят вам на ум при упоминании CI/CD pipeline? Вероятнее всего, это Gitlab CI/CD, Jenkins CI, Azure DevOps. На самом деле инструментов десятки, но так было не всегда. Ещё недавно в крупных компаниях главенствовал Windows Server, Power Shell был лучшим другом системного администратора, новые релизы доставлялись на прод в среднем раз в квартал. Сегодня поговорим о том, что изменилось.
Меня зовут Виталий Астраханцев, я занимаюсь развитием Platform V OrchestraR — программного продукта для автоматизации DevOps-конвейера. В этой статье расскажу о нашем решении и об особенностях конвейеров для крупных компаний в целом.
Зачем понадобилось оптимизировать управление разработкой
IT больше не сопровождает бизнес — теперь это и есть бизнес. Эффективность компании напрямую зависит от эффективности процесса разработки. То, насколько хорошо организован процесс, можно определить по конкретным показателям. Например, таким:
Если компания небольшая, встать в категорию high performers легко: команд и систем немного, процессом можно управлять вручную. Но чем больше бизнес, тем выше требования к безопасности, надёжности и производительности. В enterprise к этому добавляются централизованные команды и многочисленные стандарты, которым должен соответствовать каждый релиз.
Почему мы решили разработать своё решение
В определённый момент развития IT-инфраструктуры мы в Сбере начали активно использовать DevOps-инструменты. Но функций каждого отдельного сервиса не хватало, а совмещать их не получалось: вместо стройной системы получался зоопарк.
Требовался единый инструмент, который позволил бы упростить разворачивание релизов на тестовые среды — а их количество на один релиз могло превышать 20 единиц. Это с учётом всех тестовых полигонов и унификации обязательных этапов — например таких, как передача релиза в архив программ и документации.
При этом решение должно было работать в гетерогенной сети, состоящей из нескольких несвязанных между собой сегментов с различными требованиями к безопасности.
Таких инструментов на рынке в тот момент просто не существовало, поэтому решили разрабатывать свой.
DevOps для корпорации: требования к процессу и продукту
Главное требование к DevOps-инструменту для корпорации — способность обеспечивать соответствие итогового дистрибутива любого продукта корпоративным стандартам в части набора артефактов, полноты комплекта документации, проверки кода на уязвимости и безопасности применяемых библиотек. Нужно свести к нулю любые поставки не по стандарту.
Помимо этих общих правил, важно было учесть ещё и частные требования банка:
независимость от сторонних вендоров;
гибкость настройки конвейеров на уровне команд;
контроль прохождения обязательных условий конвейера согласно требованиям производственного процесса;
использование скриптов Jenkins для сборки и разворачивания дистрибутивов;
сквозное управление конвейером при работе в разных сегментах сети;
быстрое встраивание типовых этапов в собственные конвейеры команд;
соблюдение требований кибербезопасности в части контроля прав доступа и назначения ответственных за шаги конвейера и внесение изменений;
визуальная настройка этапов конвейера.
Структура и функции Platform V OrchestraR
Продукт, который появился в ответ на этот запрос, — Platform V OrchestraR. Ниже подробно расскажу о его структуре и основных функциональных модулях.
В классическом DevOps, как правило, нет единого управления организацией пайплайна отдельных команд. Но при корпоративном подходе важно обеспечить одновременно как централизованное управление, так и возможность «спускать» конвейеры по иерархии команд крупных приложений. Поэтому мы пришли к следующей структуре:
Проект — верхний уровень иерархии. Глобальный уровень, который по структуре сопоставим с выделенным тенантом для какого-либо заказчика в мультитенантной инсталляции. На этом уровне обеспечивается необходимый уровень изоляции нижестоящих объектов, позволяющий соблюдать требования конфиденциальности.
Приложение — средний уровень, в котором ключевые функциональные отличия определяются уровнем изоляции. Согласно ролевой модели участники одного проекта могут иметь доступ только к «своим» приложениям, а администратор проекта — видеть сразу все приложения, входящие в проект.
Сервис — самый низкий уровень структурной иерархии. На этом уровне можно разделить структуру проекта на отдельные микросервисы или создать один сервис для всех микросервисов, если планируется одновременная сборка на этапе CI и единый конвейер.
Для большей наглядности проиллюстрирую структуру примером. Предположим, вы ведёте разработку внутреннего портала организации. Портал — это web- и мобильное приложение, поэтому на уровне проекта вы заводите один проект — «Внутренний портал». На уровне ниже — приложения «Web-приложение» и «Мобильное приложение». Здесь же можно разделить мобильное приложение на iOS и Android.
На уровне ниже доступны деление на отдельный сервис для каждого микросервиса, группировка или заведение одного сервиса под всё приложение. И на каждой ступени этой иерархии может быть создан свой CI/CD-конвейер.
Если приложение простое и не нуждается в иерархии этапов конвейера и разделении флагов прохождения этих этапов, можно определить конвейер на уровне проекта. Соответственно, использовать его для сборки и деплоя на тестовую и продуктивную среду.
Но в enterprise чаще встречаются сложные приложения, которые включают как legacy, так и новые сервисы на разных языках. В этих случаях нужно разделить сборку и деплой на разные конвейеры на уровне сервисов, настроив каждый из них.
Вот как визуально выглядит конвейер:
Здесь — конвейер из 5 этапов. Каждый этап — логически законченный набор последовательных или параллельных фаз, который отвечает за сборку дистрибутива или за его деплой и прогон тестов на различных окружениях.
В свою очередь, каждый конвейер включает различное количество фаз. Фаза — атомарная сущность конвейера: Jenkins-скрипт сборки/установки дистрибутива либо флаг (Quality gate), отражающий результат выполнения действия. Например, флаг ci со статусами ok или err отвечает за успешность сборки дистрибутива. Его положительное значение является обязательным условием для запуска этапа ST.
Фазы бывают ручными и предопределёнными. Ручные позволяют назначить на пользователя задание в тех случаях, когда действие нельзя выполнить с помощью скрипта. Предопределённые строятся на базе Jenkins-фаз, но для выполнения заложенной в них логики, например для передачи дистрибутива в Фонд Программ и Документации, пользователю нужно заполнить лишь несколько уникальных параметров.
На разных этапах могут использоваться разные инсталляции Jenkins и Nexus. Это позволяет работать в том числе и с несколькими сегментами сети одновременно через защищённый шлюз. В Сбере он представлен в виде компонента Platform V SOWA, входящего в состав продуктов Platform V.
Platform V OrchestraR позволяет гибко настраивать ролевую модель. Благодаря этому, с одной стороны, можно гибко распределить ответственность пользователей внутри проекта и приложения, с другой — контролировать её с помощью разграничения прав доступа к различным элементам проекта и приложения.
Настройки группы прав доступа для простоты собраны в роли по модели AWXR (Administrator, Writer, eXecutor, Reader). В зависимости от бизнес-роли пользователя (владелец продукта, системный инженер, разработчик и т. д.) настройкой можно управлять на уровне внешнего портала инструментов Platform V Works.
Текущая архитектура состоит из 13 сервисов, каждый из которых отвечает за собственную часть бизнес-логики. На схеме ниже — пример того, как OrchestraR может стать фронтальной системой всего CI/CD-конвейера в любой компании. Проекты, приложения, сервисы и конвейеры со всем содержимым хранятся отдельно от флагов (Quality gates) и всего, что с ними связано.
Думаю, самая интересная часть — возможность внешних интеграций с Jenkins, Nexus, Jira (GitLab) как системами, хранящими необходимые для прохождения по конвейеру релиз-кандидата данные, а также с ELK (OpenSearch) для передачи и анализа логов. Это позволяет пользователям вовремя получать уведомления о недоступности связанных систем в момент проведения технических работ на Jenkins или Active Directory.
Как развивается продукт
Сегодня архитектура и функциональность Platform V OrchestraR соответствуют стандартам самых требовательных enterprise-заказчиков на рынке. В частности, продукт отвечает требованиям Сбера как в части контроля и прозрачности CI/CD, так и с точки зрения гибкой интеграции в существующие процессы.
Поток требований на развитие и улучшение продукта растёт. Меняется окружение, а программные продукты, с которыми изначально был интегрирован OrchestraR, постепенно заменяются на собственные решения, разработанные в СберТехе. Всё это заставляет нас пересматривать подходы и постоянно развивать продукт.
При двухнедельном релизном цикле мы обеспечиваем регулярную поставку новой функциональности. В стратегии развития продукта упор делается на универсальность и гибкость при настройке, а также стабильность и масштабируемость. Важно, чтобы решение обеспечивало отказоустойчивость приложений при любых нагрузках, в том числе превышающих существующие показатели в виде запуска нескольких десятков тысяч сборок ПО.
Platform V OrchestraR входит в состав семейства инструментов разработки Platform V Works. Продукт можно использовать отдельно как самостоятельный сервис. Но именно в составе линейки Platform V Works он будет наиболее эффективен для enterprise-компаний, работающих с SaaS- и on-premise-решениями.
Использование совместно с другими продуктами позволяет переносить текущие процессы разработки на унифицированный стек технологий и инструментов и делиться методологией разработки.
Вместо заключения
За 5 лет работы над продуктом мы учли сотни пожеланий и замечаний к развитию функциональности. Наш опыт говорит о том, что DevOps-процессы в сегменте enterprise и в средних компаниях с небольшим количеством команд схожи до уровня масштабирования процессов.
Platform V OrchestraR подходит для организации разработки в командах меньшего масштаба, которым нужно обеспечить высокие стандарты производства ПО. В этом случае главным становится не количество конвейеров, а качество и целостность логики приложения, возможность гибкой настройки конвейеров под каждую конкретную команду, сохранение прозрачности и централизованного подхода к управлению инструментом. То есть всё то, над чем мы активно работаем сегодня.
