Хочу поделиться с вами историей о том, как мы строили процессы CI/CD для ПО, написанного для нестандартной платформы, которую многие считают «динозавром» — IBM System i aka AS/400. 
AS/400 используется многими крупными российскими банками, и все они постепенно переходят к CI/CD. Райффайзенбанк был одним из первых (если не первым), кто применил эту практику для установки программного обеспечения на платформе AS/400 в промышленной эксплуатации.
Почему мы пришли к этому
Мы уже давно движемся к автоматизации установок; нас к этому подтолкнули разные причины:- Продолжительность установки.
Из-за этого продукт долгое время недоступен для клиентов банка, а дополнительная нагрузка ложится на дежурных сотрудников ночной смены, хотя они и так заняты регламентными работами.
- Качество установки.
При переносе вручную подготовленных к установке объектов что-то может «вдруг» исчезнуть или, наоборот, появиться.
Резервное копирование изменяемых объектов полностью лежит на дежурных, и они могут случайно установить новую версию одного из объектов пакета, не сохранив старую.
Мы все прекрасно знаем, к чему это приводит.
Для каждой конкретной поставки разработчики подготовили CL-скрипт. Он проверял комплектность поставки, наличие резервной копии изменяемых объектов и установку корректной авторизации объектов, а также сам устанавливал программное обеспечение и обрабатывал нештатные ситуации.
Группе поддержки и бизнесу новый подход понравился, поскольку улучшилась стабильность установки.
Но разработчикам стало сложнее, потому что вместо простых инструкций типа «взять объект xxx, перейти в другую среду, поставить 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.
Сборка
К сожалению, скомпилировать программы RPG/CL на машинах *nix или Windows невозможно, поэтому пришлось немного усложнить стандартную схему сборки ПО:
Для себя мы сразу определили «эталонную» среду AS/400, в которой агенты Bamboo выполняют удаленную компиляцию.
Создавая новое программное обеспечение, разработчик заранее заботится о том, как оно будет собрано и установлено в дальнейшем.
Для этого каждое программное обеспечение в Bamboo имеет свои собственные сценарии сборки и развертывания.
После фиксации автоматически запускается план сборки приложения в Bamboo, настроенный для конкретного репозитория.
Исходный код загружается и помещается в агент сборки, а затем через FTP помещается во временную библиотеку сборки на AS/400. Затем программа-сборщик приложений компилируется через ssh и вызывается.
Задача сборщика — скомпилировать все программы и установщик, а затем поместить их в один пакет, готовый к развертыванию в любой среде.
Типичный пакет программного обеспечения, готовый к установке: 
Готовый пакет затем передается по FTP из AS/400 в агент сборки.
Здесь следует отметить, что смена программ – это только одна часть изменения, а вторая – скрипты изменения базы.
Они перемещаются из Bitbucket в агент сборки и добавляются как еще один артефакт в уже созданный программный пакет AS/400. После завершения сборки артефакты публикуются в Bamboo и Artifactory. Планы сборки в Bamboo разработаны таким образом, чтобы их можно было применять к любому программному обеспечению AS/400, написанному в банке.
На добавление нового плана у нас уходит 15 минут — при этом учитывается клонирование любого другого плана и изменение значений некоторых переменных.
Монтаж
Одним из основных преимуществ нашего процесса установки является то, что он повторяем и одинаков для любой среды, будь то производственная среда или среда разработки.Тестирование установки в продакшене мы начинаем уже на этапе установки в среду разработки.
В общих чертах установка выглядит так: 
Нажатие триггера или кнопки запускает план развертывания в Bamboo для указанной среды.
Первым делом из Artifactory в установочный агент загружаются наши артефакты — это скрипты Liquibase и установочный пакет ПО (файл сохранения).
Объекты файла сохранения затем перемещаются через FTP и распаковываются во временную библиотеку на AS/400 в среде, где будут установлены программы.
Далее запускается утилита Liquibase, которая с помощью библиотеки jt400 подключается к AS/400 и выполняет скрипт обновления базы, записывая соответствующие записи в журнал изменений.
Наконец, Bamboo вызывает по ssh установщик, который создает резервную копию измененных объектов, проверяет содержимое поставки, устанавливает изменение и настраивает авторизацию.
Результат установки отправляется всем членам команды, подписавшимся на рассылку: 
Мы добавили небольшую полезную функцию: обновлённая версия ПО на программном уровне помечается номером задачи, в которой было сделано последнее изменение, и идентификатором коммита в Bitbucket: 
Это поможет вам быстро найти последние изменения и увидеть изменения в коде.
В экстренных ситуациях даже команда поддержки может внести небольшие изменения в код и отправить исправление в производство, не обладая ценными знаниями о компиляции, сборке и установке программного обеспечения.
В настоящее время мы выполняем около 150 установок в день в средах AS/400. Мы постоянно совершенствуем процесс, он не высечен в камне и не закреплен в стандартах и процедурах – он живет и развивается.
Разработчики все больше воодушевляются, у них появляются новые идеи, они предлагают новые улучшения.
Служба поддержки пытается воплотить эти идеи в жизнь, предлагая по ходу свои изменения.
Эти инструменты и процессы помогают нам не только поддерживать и быстро доставлять программное обеспечение в производство, но и объединять нас в команду DevOps. Теги: #ИТ-инфраструктура #Системное администрирование #DevOps #ci/cd #raiffeisenbank #rpg #iseries #as400
-
Как Pinterest Поддерживает Устойчивый Рост
19 Oct, 24 -
Эксплуатация Tesla В России: Факты И Ответы
19 Oct, 24 -
Интересное В Закладках Ux/Ui Дизайнера
19 Oct, 24 -
Рекламные Агентства Горят :)
19 Oct, 24 -
Гаджет Для Моддеров От Gigabyte
19 Oct, 24 -
Обзор Криптоэкономики. Перевод Статьи
19 Oct, 24
