В нашей прошлой статье мы рассказали о том как строили централизованный конвейер, но описали его довольно поверхностно. Это породило массу вопросов, которые мы не можем оставить без ответа. Здесь мы попробуем максимально глубоко залезть «под капот» и рассказать, как работает наш централизованный конвейер.


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

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

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



Закончив с задачей, разработчик заводит в Bitbucket pull request на внесение своих изменений в основную ветку. И тут он впервые сталкивается с проявлением работы конвейера: pull request запускает процесс автоматической ревизии кода.

Ревизия у нас выполняется с помощью SonarQube, интегрированного в конвейер через плагины Sonar for Bamboo и Sonar for Bitbucket. При регистрации pull request’а в Bamboo автоматически запускается план сборки, анализирующий ветку, которую хотят добавить. Результат анализа выводится прямо в pull request вот в таком виде:



В форме pull request’а сразу видно, какие новые замечания содержит код, их критичность, категория и т.д. Сами замечания можно посмотреть непосредственно из формы pull request’а, достаточно перейти на вкладку Diff.



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

Следующим этапом идет сборка из нашего кода чего-то нужного и полезного. Сборка запускается в Bamboo самыми разными способами. Можно вручную, можно автоматически по факту слияния или коммита в репозитории, по расписанию, или вообще через вызов Bamboo Rest API. Для простоты и наглядности рассмотрим самый банальный вариант — запуск сборки руками. Для этого надо зайти в Bamboo, выбрать нужный план и нажать старт.

После запуска по указанным в плане зависимостям подбирается подходящий агент, на котором будет выполняться сборка. На данный момент у нас есть 30 Windows-агентов, 20 Linux, 2 iOS-агента, и ещё 5 мы держим под эксперименты и пилоты. Половина агентов развернуты в нашем внутреннем облаке, но об этом чуть позже. Такое количество позволяет нам бесперебойно обслуживать более 500 активных сборочных планов и примерно пару сотен проектов развёртывания.

Но вернемся к нашему сборочному плану. Конвейер поддерживает все распространенные инструменты сборки, перечень которых может быть расширен с помощью плагинов.



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



Сформированный в результате сборки артефакт автоматически размещается в Artifactory.



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

Разместив пакет в Artifactory, мы можем делать с ним всё, что угодно, в том числе и устанавливать на нужную нам среду. Как правило, команды используют три среды для создания ПО. Dev-среда — среда разработки, используется для разработки и отладки. Test-среда — используется для функционального и интеграционного тестирования приложений. Preview-среда — используется для приемки функциональности заказчиком и нагрузочного тестирования; как правило, она ближе всего к условиям рабочей эксплуатации. У некоторых команд еще принято перед установкой в production проводить установку на вчерашнюю копию рабочей среды, что тоже помогает выявлять проблемы.

Команды совместно с поддержкой решают, кто и в какие среды устанавливает, и тут у нас используются практически все варианты. Есть команды, у которых за развёртывание отвечают только разработчики (привет, DevOps!); есть команды, где разработчики обновляют только dev и test, а поддержка — preview и prod. В некоторых командах вообще есть специально выделенные люди, занимающиеся установкой во все среды.

Развёртываемый проект представляет из себя набор сред, связанных с определенным планом сборки.



Среда содержит средозависимые переменные, настроенные для каждой среды отдельно. В комментариях к прошлой статье был вопрос о том, как мы храним пароли. Как видно на скриншоте, мы храним их в параметрах планов сборки и развёртывания. В Bamboo реализован механизм шифрования паролей: достаточно в имени переменной использовать слово password, и она будет зашифрована. После сохранения, значение такой переменной уже невозможно будет просмотреть через интерфейс или увидеть в логах выполнения, оно везде будет «замаскировано» звездочками.



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



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



Про установки в production, наверное, стоит поговорить отдельно. В банке есть процесс регистрации изменений (CM), согласно которому все изменения в production должны быть заранее объявлены и согласованы. Для регистрации изменений команда заводит change management request (CRQ) не менее чем за три дня до установки. К этому CRQ прикладываются всевозможные отчеты по тестированию, формируется внушительный список согласующих. Процесс достаточно медленный и громоздкий… Но мы же развеиваем мифы об IT в банках

У нас есть команды, которые совместно с бизнесом и поддержкой решили, что делают всё настолько хорошо, что готовы вносить в production любые изменения и в любое время, и это не приведет к плачевным последствиям. Специально для таких команд был придуман процесс упрощенной регистрации и согласования изменений в production-системе, в рамках которого можно в любое время вносить изменения в production, а регистрировать CRQ уже по факту проведенных работ. Но какой же это CI/CD, если надо какие-то заявки заводить вручную… Поэтому мы написали собственный плагин для Bamboo, позволяющий автоматически регистрировать CRQ, который встраивается в план развёртывания.



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

В современных реалиях, рассказывая о процессе развёртывания, нельзя обойти вниманием такую вещь, как облака. Как мы уже писали, что у нас есть внутреннее облако на базе VMWare vRealize. Оно используется как в непромышленных средах, так и в production. Облако мы тоже интегрировали в конвейер с помощью еще одного собственного плагина. Теперь через Bamboo мы можем создавать или удалять серверы в облаке.



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



Таким образом, благодаря коробочным интеграциям и небольшой кастомизации, мы смогли построить CI/CD-конвейер, способный решить все поставленные задачи. Но ничто не стоит на месте. Сейчас мы (как и всё прогрессивное человечество) активно движемся в сторону интеграции конвейера с инструментами chatops, использования контейнеров и автоматизации процессов, связанных с самим конвейером.

В комментариях к прошлой статье задали ещё ряд вопросов, на наш взгляд, не имеющих отношения ни к CI/CD, ни к конвейеру. Так что ответим на них в формате «вопрос-ответ». Вероятно, ответы покажутся вам однообразными. Но в банке более 700 приложений написанных в разное время, под разные ОС и с использованием разных технологий, поэтому дать однозначный ответ невозможно, в большинстве случаев всё определяется приложением и его командой.

Какие схемы развёртывания используются? (green/blue, rolling, canary и т.д.). А если надо откатиться?

Зависит от конкретного приложения. Насколько я знаю, точно есть green/blue и rolling, насчет остальных не уверен. Команды сами выбирают оптимальный вариант развёртывания. Если надо откатиться и это возможно, то откатываемся.

Как и кем принимается решение об успешном развёртывании? На основании каких параметров?

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

Что делать, если нагрузка увеличивается? Легко ли добавить больше серверов, чтобы удержать нагрузку? Если ли автомасштабирование?

Зависит от приложения и еще очень многих и многих факторов, как и всегда, когда дело касается нагрузки. Автомасштабирование не используется.

Каждое новое развёртывание выполняется на вновь созданные серверы или на те же самые?

Зависит от приложения. Наша команда пересоздает серверы каждые две недели, и развёртываем только на новые. Другие команды развёртывают всегда на одни и те же серверы. Команды сами выбирают подход.

Что с патчами на операционную систему?
Зависит от приложения, ОС и обновления. Но, в итоге, все критичные исправления у нас установлены и уязвимостей нет.

А что с мониторингом и метриками приложений и системы (OS)?

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

Что используете для балансировки нагрузки между копиями приложений? nginx/haproxy/etc?

Зависит от приложения Есть и nginx, и haproxy, и NLB, и железная Cisco.