Я хочу поделиться с вами историей, как мы строили CI/CD-процессы для ПО, написанного для нестандартной платформы, которую многие считают «динозавром» — IBM System i aka AS/400.


AS/400 используется многими крупными российскими банками, и все они потихоньку движутся в направлении CI/CD. Райффайзенбанк стал одними из первых (если не первым), кто применил эти практики для установки ПО на платформе AS/400 в промышленной эксплуатации.

Почему мы к этому пришли

К автоматизации установок мы шли давно, нас к этому подталкивали разные причины:

• Длительность установки. Из-за этого продукт долго бывает недоступен для клиентов банка, а на дежурных сотрудников ночной смены ложится дополнительная нагрузка, хотя они и так заняты регламентными работами.
• Качество установки.При ручном переносе подготовленных к установке объектов может что-то «внезапно» пропасть, или, наоборот, появиться. Бекап изменяемых объектов — полностью на совести дежурных, и они нечаянно могут установить новую версию одного из объектов пакета, не сохранив старую. К чему это приводит, мы все прекрасно знаем.

После нескольких неудачных установок мы решили включать в любую установку на AS/400 специальную программу-установщик. Для каждой конкретной поставки разработчики готовили CL-скрипт. Он проверял полноту поставки, наличие бекапа изменяемых объектов и установку правильной авторизации на объекты, а также сам устанавливал ПО и обрабатывал нештатные ситуации.

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

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

Кроме того, у нас всегда уходило много времени при переходах поставки от стадии к стадии. После написания кода разработчик спрашивал тестировщика: «Куда ставить-то?»; тестировщик через некоторое время отвечал и переводил задачу на разработчика; тот устанавливал и отправлял задачу обратно. Потом начинались «перекидывания мяча» при исправлении найденных дефектов, при подготовке поставки к выходу в бой. В лучшем случае, на каждый такой переход тратилось несколько минут, в худшем — дни.

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

Новые инструменты AS/400

С возникновением в нашем банке движений CI/CD и DevOps, мы получили новые инструменты и сразу начали их осваивать.

Исходный код переместился в соответствующее хранилище — Git (Bitbucket), собранные поставки — в Artifactory, а процесс сборки, установки и тестирования — в Bamboo.

Если исходные коды RPG/C/CL более-менее гладко легли в хранилище кода, ведь это просто текст, то с оркестратором сборок и установок (Bamboo) пришлось повозиться, потому что стандартных плагинов Bamboo для AS/400 в данный момент не существует.

Мы начали пробовать различные варианты установок. Концепции были абсолютно противоположными, начиная с «давайте всю логику установки и сборки хранить в Bamboo в виде ftp/ssh-скриптов, без какого-либо дополнительного кода», заканчивая, «а давайте сделаем универсальный установщик на AS/400».

В итоге у нас получился процесс, который практически ничем не отличается от процессов CI/CD для любой другой платформы:


Центральное звено процесса — Jira, в ней собирается вся информация о требованиях, документации, коммитах, сборках и установках.


Все требования у нас появляются в виде Jira-задач и попадают в работу к аналитикам, которые выясняют и описывают требования и сценарии использования ПО, после чего задачу вытягивают на себя разработчики.

Разработчики пишут код и публикуют его в Bitbucket. Идентификатор коммита и ссылка на него автоматически появляется в Jira-задаче.
Коммит в Bitbucket автоматически запускает сборку приложения в Bamboo и публикацию собранной поставки в Artifactory.

Когда сборка успешно завершается, она запускает план установки ПО в «песочницу» разработчиков, где они могут проверить то, что у них получилось. Также после успешной установки запускается набор автотестов, информирующий разработчика о качестве новой поставки. Информация о статусе установок сразу же отражается и в Jira-задаче, и в Bitbucket.

Если дефектов нет, то разработчик может приступать к следующей задаче.

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

После окончания тестирования создается «запрос на изменение» для специалистов поддержки, которые валидируют и согласуют изменение. После этого дежурные в нужный момент жмут кнопку для установки в Bamboo.

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

Теперь предлагаю немного погрузится в подробности сборки и установки на AS/400.

Сборка

К сожалению, на *nix- или Windows-машинах нельзя компилировать RPG/CL-программы, поэтому нам пришлось немного усложнить стандартную схему сборки ПО:

Для себя мы сразу выделили «эталонную» среду AS/400, на которой агенты Bamboo делают удаленную компиляцию.

Разработчик, создавая новое ПО, заранее заботится о том, как оно в дальнейшем будет собираться и устанавливаться. Для этого у каждого ПО в Bamboo есть свои Build- и Deploy-скрипты.


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


Исходный код выкачивается и размещается на сборочном агенте, а потом по FTP кладётся во временную сборочную библиотеку на AS/400. Затем по ssh компилируется и вызывается программа-сборщик приложения. Задача сборщика — скомпилировать все программы и установщик, а потом поместить их в один пакет, готовый к развертыванию в любой среде.

Типичный пакет ПО, готовый к установке:


Затем готовый пакет по FTP переносится с AS/400 на сборочный агент.

Тут надо отметить, что изменение программ — только одна часть изменения, а вторая — это скрипты по изменению БД. Они перемещаются из Bitbucket на сборочный агент, и присоединяются как еще один артефакт к уже собранному пакету AS/400-программ.

После окончания сборки артефакты публикуются в Bamboo и Artifactory.

Сборочные планы в Bamboo составлены так, чтобы их можно было применить для любого ПО под AS/400, написанного в банке. Для добавления нового плана нам требуется 15 минут — здесь учтено клонирование любого другого плана и изменение значений некоторых переменных.

Установка

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

В общих чертах установка выглядит так:


По триггеру или нажатию кнопки запускается план развёртывания в Bamboo для указанной среды. Первым делом из Artifactory на установочный агент выкачиваются наши артефакты — это Liquibase-скрипты и установочный пакет программ (save-файл).

Затем объекты save-файла по FTP перемещаются и распаковываются во временную библиотеку на AS/400, в среде, куда будут устанавливаться программы. Далее запускается утилита Liquibase, которая с помощью библиотеки jt400 подключается к AS/400 и выполняет скрипт обновления БД, занося соответствующие записи в лог изменений.

Наконец, Bamboo по ssh вызывает программу-установщик, которая бэкапит изменяемые объекты, проверяет содержимое поставки, ставит изменение и корректирует авторизацию.

Результат установки отправляется всем подписанным на рассылку членам команды:


Мы добавили маленькую полезную функцию: у обновленной версии ПО на уровне программ проставляется номер задачи, в рамках которой сделано последнее изменение, и ID комитта в Bitbucket:


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

Сейчас мы проводим около 150 установок в AS/400 среды в день. Мы постоянно улучшаем процесс, он не выбит в камне и не зафиксирован в стандартах и процедурах — он живет и развивается. Разработчики всё больше входят во вкус, у них появляются новые идеи, они предлагают новые улучшения. Поддержка пытается воплотить эти идеи в жизнь, попутно предлагая свои изменения. Эти инструменты и процессы помогают нам не только в поддержке и быстрой поставке ПО в продуктив, но и объединяют нас как DevOps-команду.