В одном из предыдущих постов про DevOps мы обещали рассказать про технологическую составляющую нашего CI/CD-конвейера.

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

О себе

Я работаю в Raiffeisen более пяти лет. Сначала был внештатным специалистом, а сейчас руковожу подразделением, которое поддерживает CI/CD-конвейер и развивает автоматизацию. За этот немаленький промежуток времени мне и команде удалось поработать, наверное, с 90% всего используемого в банке ПО, получить много полезного опыта, частью которого я и хотел бы поделиться.

Что было в части используемых технологий и подхода два года назад и к чему мы пришли

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

Команды разработки использовали совершенно разные языки программирования, фреймворки и инструменты. Команды поддержки тоже пользовались тем, чем умеют, с разной долей успешности. То есть у Dev были свои инструменты, у Ops — свои. Автоматизация если и была, то на уровне «cmd вызывает батник, тот запускает VBS-скрипт, который создает объект в COM+, который...» НЕТ, ВСЁ, НЕ ХОЧУ ЭТО ВСПОМИНАТЬ!

Итак, про технологии. Начнем с CD, если это можно так назвать.

Несколько инсталляций subversion, в простонародье — SVN, парочка подпольных инсталляций GIT, всё это крутится либо на замечательной Win 2003, либо на новеньком <иронично> RHEL 5. И конечно же не связано между собой, от слова НИКАК. Многие предпочитали вообще не использовать системы контроля версий. База знаний и документации велась либо там же в SVN (да-да) в виде инструкций msdoc, либо на каких-то внутрикомандных wiki.

Нужно отметить, что были 3-4 команды, которые активно выстраивали свой автоматизированный процесс. Что не могло не радовать. Но их опыт трудно было масштабировать из-за количества и различий в используемых технологий. Jenkins, TeamCity, Bamboo, Artifactory, Nexus, в общем, каждый делал что хотел и как умел.

«Мы построим свой конвейер, с блэкджеком и куртизанками»

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

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

Система управления тестированием была не менее прекрасна — HP ALM. Как к системе отслеживания багов претензий у меня к ней нет, вся беда в интеграции. Но возможно, что это просто моя личная «любовь» к программным продуктам HP.

Первым важным изменением в нашем зоопарке, с моей точки зрения, стало появление Jira. После Remedy это был глоток свежего воздуха: легкая, быстрая, удобная! Сначала Jira решили попробовать несколько команд разработчиков, и в итоге она стала общебанковской системой. На первых порах в неё перенесли все работы по непромышленным средам, а сейчас мы внедряем JIRA SD в качестве системы управления инцидентами и изменениями. Важно и то, что в JIRA начали совместно работать над задачами как Dev, так и Ops. Не заставила себя долго ждать и Confluence.


Затем мы взялись за централизацию всех систем хранения исходного кода. Подняли централизованный стенд SVN, в который перенесли репозитории всех команд. Также в качестве альтернативы SVN подняли Bitbucket, и многие команды сразу перешли туда. В результате весь самописный код стал храниться в двух продуктах, и каждая команда решала самостоятельно, чем ей пользоваться.

К этому моменту уже созрела идея создания полноценного конвейера для автоматизации CI/CD. Самые жаркие споры шли вокруг выбора инструмента для автоматизации сборки и установки ПО, а также инструмента для хранения бинарных объектов. Мы очень долго присматривались к имевшемуся на рынке, сравнивали, читали, изучали, что-то пробовали и проверяли, в том числе разработанный в нашем головном офисе в Вене самописный инструмент.

В итоге по нескольким причинам остановились на Bamboo:

• Из коробки иного плюшек в интеграциях с продуктами Atlassian.
• Отсутствующие возможности на 90% покрываются доступными плагинами.
• Есть подготовленный, развиваемый SDK для написания своих плагинов.
• Поддержка от крупного вендора.

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

В качестве инструмента для хранения бинарных объектов выбрали Artifactory. На сравнение и выбор между Nexus и Artifactory у нас ушло около месяца. Разные источники в интернетах говорили о превосходстве то одного, то другого инструмента. Нам подходили оба, но в конечном итоге победила лицензионная политика Jfrog. И мы до сих пор ни разу не пожалели о своем выборе, инструмент удобный, активно развивающийся.

За пару месяцев мы подняли и интегрировали непромышленные и промышленные среды конвейера. В качестве ОС для всех продуктов без особых размышлений выбрали RHEL 7, а в качестве СУБД — PostgreSQL.

Начался увлекательный процесс перехода команд на централизованный CI/CD-конвейер. Чем больше их переходило, тем больше ПО нужно было установить на агенты Bamboo. Поясню: на установку и отладку около 45 компонентов на 10 агентах ушло примерно 5 месяцев.

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

Команда поддержки автоматизации не умеет автоматизировать! WTF?!

Учитывая, что со временем Bamboo-агентов станет гораздо больше 25, для создания и обновления агентов решили использовать связку Bamboo и Ansible. Чем Ansible для нас оказался интереснее других инструментов управления конфигурациями:

• легкостью в освоении,
• отсутствием серверной части,
• ну и всеми остальными преимуществами подобного ПО.

На подготовку первой бета-версии сценариев для RHEL-агентов ушло около двух месяцев. С Windows, как всегда, было много проблем, здесь уже потратили 3-4 месяца. При этом до сих пор ведём войну с nuget и chocolatey. Но зато на создание и конфигурацию агента теперь уходит вместо двух недель всего два часа. К слову, сегодня у нас ~50 агентов, а количество устанавливаемых компонентов приближается к 120. Казалось бы, вот оно счастье, два часа — и новый агент готов! Но нет. Создание нового сервера — не менее прекрасная история, учитывая количество команд, вовлеченных в этот процесс. Со всеми согласованиями и управлением изменениями, мы тратили на создание нового RHEL-сервера около недели. А потом еще пару дней на передачу рута.

With great power comes great responsibility.

Надо было что-то менять.

Начали думать. Между делом добавили в конвейер SonarQube — инструмент для статического анализа кода и управления техническим долгом. Классное ПО!

Но вернёмся к нашим баранам: в эпоху IaaS было очень больно осознавать, что неделю создаём виртуалку. А почему не использовать AWS/GoogleCloud/Azure или любое другое облако? Ответ прост — законодательство РФ запрещает, да и наша служба безопасности была не в восторге (мягко говоря) от идеи использования внешнего облака.

Тогда сделаем своё!

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

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

Но на этом мы решили не останавливаться. Если автоматизировать, то нужно научиться создавать серверы в vRealize из Bamboo. Неделя исследований и еще неделька на реализацию собственного плагина — и первый сервер создан прямо из deploy-проекта Bamboo. К тому моменту народ решил, что нам совершенно не нужен SVN, а вместе с ним и Fisheye+Crucible: у Bitbucket гораздо больше возможностей, он современнее и удобнее. Мы помогли командам переехать на Bitbucket и выключили «отслуживший своё» SVN.

Что бы еще автоматизировать?

Dev/Ops/DevOps/BizDevOps — что мешает всем этим людям при наличии автоматизированной сборки и установки? Работа с запросами системы управления изменениями! Но как же нам быть без управления изменениями, это же важная штука! <лукаво> Если рассмотреть ситуацию внимательнее, то становится понятно, что мешает не сам процесс, а необходимость планировать, согласовывать и фиксировать результат изменения ВРУЧНУЮ!

И на помощь снова приходит возможность написания собственных плагинов для Bamboo! Неделя исследований, две недели на реализацию, и мы создаем из того же deploy-проекта первый предсогласованный CRQ в промышленной среде.

Чем занимаемся сейчас?

Мы запустили пилотное использование нескольких инструментов для ChatOps. Тащим за HipChat, потому что несмотря на все его недостатки, лучшего onpremise-решения я пока не нашел. Опять же, за счет использования большого стека продуктов Atlassian мы получим кучу плюшек. Например, интеграция всех инструментов позволяет в Jira-задаче отслеживать все коммиты, сборки и развёртывания, выполненные при реализации этой фичи. Включение в процесс HipChat позволит, например, устанавливать определенный релиз в конкретное окружение, прогонять автотесты, возвращать результат в чатик и отправлять пользователям уведомления о том, что можно приступать к UAT, введя одну команду в окно чата…

Наш конвейер сейчас выглядит так:


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

Обещаем еще вернуться и поделиться новым интересным опытом.