Автоматизируй производство в стиле handmade

    Привет!

    История становления и развития свойственна не только людям. Совершенствуя себя, мы совершенствуем и те вещи, которые делаем.



    Не исключение и наш Банк, со временем обросший паутиной многочисленных IT-решений, в центре которой находится автоматизированная банковская система Equation (АБС). Меня же зовут Кирилл Диброва. Я занимаюсь функциональным и архитектурным развитием Equation — огромного и весьма важного для Банка программного комплекса; совсем не похожего на типичные реализации современного разработчика.

    В этом посте хочу рассказать вам о той вынужденной «промышленной революции», которую пришлось осуществить devops-инженерам АБС. Итак…

    Начало пути


    Давным-давно, в забытом 2002-ом, в «далекой-далекой галактике», разработчики нашего Банка начали дорабатывать «свежевнедренную» и вполне популярную на тот момент АБС Equation. Как оказалось, это такой огромный бизнес-монолит, крутящийся под мейнфреймом IBM, именуемым, на тот момент, AS/400. И использовали они для этого вполне “современный” на то время IDE – терминальный редактор SEU (source entry utility)


    SEU, «современный» редактор исходных текстов для IBM i

    Согласитесь, сейчас выглядит, как спецэффекты в “Звездных войнах” 78-го года — сурово и беспощадно.

    Где-то в середине нулевых компания IBM все же смилостивилась над свои разработчиками и выпустила «Rational Application Developer for iSeries» (позже Rational Develop for I или сокращенно Rdi). Жить стало веселей — это и современные оконный интерфейс, и довольно удобный инструментарий для взаимодействия с сервером, и поддержка синтаксиса основного языка разработки RPGLE. Но, тем не менее, код все так же хранился и правился в рамках специализированной файловой системы мейнфрейма. А без полноценной истории изменений и иных важных фишек SCM работать над кодом совместно было весьма сложно.

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

    Познай себя


    Банк развивался – развивалась и увеличивалась и команда развития АБС. При приближении к двум десяткам разработчиков начали всплывать очевидные проблемы: найти актуальный код довольно проблематично, одновременная правка одного и того же файла стала неразрешимой задачей. Отдельная история была со сборкой и развертыванием. Ведь ставилось приложение скриптом. И при этом разработчики часто копипастили нужные куски кода из одного «батника» в другой, забывая изменить их под свои особенности развертывания.

    Такие побочные затраты на мелочь могли пройти незамеченными. Но наступил 2013 год., и разработчиков стало уже 50. При этом каждый тратит примерно час в неделю на привычную рутину — сборку кода в поставку, запуск отладочных тестов, «doc»-и технической спецификации. Как оказалось, в месяц эти «мелочи» сложились в сотни человеко-часов. А devops-стихия докатилась, наконец, и до нашего Банка.

    Тренировка


    Что хотелось сделать, когда перед нами поставили задачу «автоматизировать»?
    Ну, для начала хотелось получить единое и, что немаловажно, удобное хранилище исходного кода. Желательно с опытом работы у большинства разработчиков, чтобы не тратить время на обучение. И ура — в это время в Банке как раз развернули Atlassian-стек со Stash-ом (оболочка для git, сейчас называется Bitbucket), под постепенную замену svn. На волне всеобщего перемещения туда же “заехали” и мы.

    Супер! Одна хотелка воплотилась в жизнь.

    Но остался один нюанс — тексты по-прежнему должны были быть скопированы на сервер для компиляции и развертывания. При использовании RDi это можно было сделать без особых проблем. Правда, вести одновременно проект в RDi и git довольно неудобно. RDi работает с «родной» файловой структурой сервера и накладывает свои ограничения на структуру проекта.
    Попробовали iProject, который наследует эту специфику. Да, он позволяет работать с исходниками на локальных машинах, имеет встроенную поддержку git. Но ограничен исключительно линейной структурой проекта, отягощен метаданными для совместимости с родной файловой системе IBM i.

    Одним словом, полно всяких ограничений и в целом также неудобно как и работа с SEU.


    Так выглядит RDi — IDE от IBM

    Надо искать дальше.

    Следующая хотелка — сделать конфигурацию развертывания унифицированной. Главное, с минимальной спецификой или вовсе «без самодеятельности». Пришлось подбирать комплексный инструмент для Continuous Integration.

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

    Наши требования были следующими:

    • должен поддерживаться git в качестве хранилища исходных кодов;
    • должен быть инструмент для автоматизации процесса в целом как, например, jenkins или atlassian bamboo, или поддержка использования вышеупомянутых комплексов;
    • проект должен иметь гибкую файловую структуру проекта а-ля maven от apache;
    • сценарии доставки должны быть гибкими и позволять использовать по-максимуму уже существующие инструменты для компиляции и развертывания;
    • инструментарий должен позволять писать тестовые сценарии разного уровня.

    В целом все коммерческие продукты отличаются поддержкой распространенных инструментов. Но сложности начинаются, когда дело доходит до особенностей интеграции в конкретных условиях организации. Продукты от ключевых поставщиков IBMi-автоматизации — компаний ARCAD и UrbanCode, к сожалению, разочаровали. Прежде всего отсутствием гибкой интеграции с нашим сервером. Адаптировать внешние решения под уже используемые нами инструменты компиляции было либо слишком дорого, либо вовсе невозможно.

    Оценив сложности, перспективы и необходимые вложения, решили пойти собственным путем — построить свой лунапарк, с “инсами” и автотестами.

    Начали вроде бы с простого, с определения языка нотации, на котором будем описывать сборку. Изначально пробовали JSON. Он прост и понятен, очень распространен.


    JSON-декларатив для проекта

    Но при этом для JSON пришлось бы писать собственный парсер конфига и реализовывать все сборочные фичи «с нуля». Выглядело не очень впечатляюще.

    Поштормив разные варианты, пришли к выводу, что лучше использовать уже готовый инструмент, предоставляющий базовые “плюшки из коробки”. Но при этом адаптируемый под наши требования. Остановились на сборщике последнего поколения – gradle. Наследует возможности и maven, и ant, прост в конфигурировании, расширяется плагинами, обладает гибкостью сборки по зависимостям, вполне скоростной, т.к. поддерживает кэширование в инкрементальных сборках.

    В итоге через 4 месяца удалось выпустить первую версию собственного gradle-плагина для сборки и развертывания приложений под мейнфрейм IBM i.

    Сборщик выполнил свою функцию на «ура»! Спрятал в себе всю «кухню» доставки кода на сервер и компиляции, опубликовав потребителю типичные task-и: «собрать и развернуть на dev», «сформировать и опубликовать поставку», «развернуть поставку на среде». Стоит отдать дань уважения IBM за публикацию пакета jt400.jar, который позволяет полноценно работать со всеми сервисами IBMi через java-интерфейс.

    Из ручного скрипта развертывания на командном языке операционки:


    CL — основной язык для скриптов развертывания на сервере

    перешли на совершенно новый уровень описания build-а.

    Описание сценария стало «красивым», но не перестало занимать время. Только через несколько месяцев «мучений» перешли на декларативное описание приложения и «экономный» build.gradle:







    Вот такие «накопительные» скрипты теперь пишут разработчики

    А еще через некоторое время пришли и к поддержке модульности:


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

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

    Развитие


    Стоит отметить, что, как и во многих иных организациях, сформировать постоянно выделенную на devops-нужды команду нам не удалось. В итоге поддержка и доработка CI-инструментов осуществляется всем сообществом IBMi-разработчиков. По крайней мере мы стараемся прийти к распределенной и сбалансированной «контрибуции». Если кому-то нужна какая-то доработка, он делает это сам.

    Таким образом, освоив и стабилизировав базовый CI-функционал, вспомнили про автоматизированное управление качеством. Сборка есть, доставка — есть, тестов нет. Чего-то внятного и распространенного, как оказалось, для платформы нет. Есть опять же ARCAD, но от него отказались еще на прошлом этапе. Мы вполне понимали, что добавление автотестирования — это весьма важный эволюционный шаг, без которого не бывает полноценного Continuous Integration; должных скорости и качества без этого не достичь. Также сразу учитывали, что придется менять многолетние привычки по кодированию тестов, и это отдельная история, которую предстояло пройти.

    В Альфе развитие автотестирования развивалось двумя параллельными историями: автотесты пользовательских интерфейсов через GUI и тестирование без GUI (мы же все-таки backend-разработчики). При этом продуктовые команды самостоятельно пилили инструменты, в первую очередь под свои нужды.

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

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



    На мероприятии команды могут познакомить других разработчиков со своими наработками, получить фидбэк, наладить межкомандные взаимодействия. Митап стал неким рынком-супермаркетом: у всех есть что-то интересное, что можно попробовать другим; а если уже успели попробовать, то обсудить дальнейшее развитие и, возможно, получить соответствующую помощь. Кроме сообщества Альфа-Банка участвуют еще и разработчики из других компаний. Поэтому ежегодный IBMi Dev MeetUp стал для нас важной информационной площадкой, двигателем прогресса в сообществе, местом обмена знаниями и технологиями.

    На текущий момент развитие производственного инструментария самим сообществом — это основной двигатель прогресса в автоматизации разработки на стеке IBM i. Каждый может прийти с предложением, каждый может поучаствовать в развитии CI/CD и этим прокачать свои «скилы». Мы часто говорим о мотивации. Говорим, что нас заставляют заниматься шаблонными задачами в угоду бизнеса. В нашем же случае речь про другое. Речь про творческую, исследовательскую работу. Здесь разработчики могут, соблюдая определенные рамки, сам принимать решения что делать и что не делать, их не надо заставлять работать больше или меньше. Все делается «по вштыру». В итоге же получается не продукт, который можно гордо положить в стол. Совсем нет. Получается продукт, которым пользуются все коллеги в организации. А сейчас мы применяем подход, когда продуктом могут пользоваться (и покупать) другие компании. Проходим сертификацию Роспотребнадзора. Вот, например, наша публикация про софт, который прошел такую сертификацию.

    Планы на будущее


    Инструментарий CI/CD активно продолжает развиваться и оптимизироваться. Например, продолжается работа над системой зависимостей между объектами внутри одного проекта так и между проектами. IBM тоже не стоит на месте и внедряет новые, удобные фишки в свои средства разработки.

    Возможно, кто-то из читателей не только заинтересуется нашим опытом, но предложит дельные идеи по дальнейшему пути совершенствования. Будем только рады вашей поддержке.

    Спасибо.

    Comments 5

      0
      это основной двигатель прогресса в автоматизации разработки на стеке IBM i


      Очень интересная статья, довелось работать на ЕС ЭВМ, вот эта картинка вызвала легкий наплыв приятной ностальгии.

      Вот вопрос — есть ли сейчас какие-то плюсы в использовании именно стека IBM i, или тут, в основном, все связано с некоей уникальной функциональностью АБС Equation?
        0
        Вот вопрос — есть ли сейчас какие-то плюсы в использовании именно стека IBM i, или тут, в основном, все связано с некоей уникальной функциональностью АБС Equation?


        Про плюсы и минусы вопрос скорее к сопровождению (Андрей Шмаков, например).

        Из общих соображений — в свое время была выбрана эта АБС и платформа на которой она работает. Каких-то явных минусов, которые могли бы подвигнуть на смену системы тут точно нет.
          0
          SEU уже не застал (ну кроме первой учебной задачки), застал конец «эпохи» iProjects и «переезд» в GIT и gradle. Это, конечно, была революция в плане производительности. Хотя потребовалось некоторое количество усилий по перетаскиванию всего в GIT. Конвертация исходников в UTF8, прописывание gradle скриптов по существующим инсталяторам…

          Все что описано в статье — огромная работа. И выполнена она отлично. Так что от всех разработчиков Кириллу и всем, кто это делал и внедрял огромное спасибо!
            0
            Ну так а выпустить ваш плагин в ос не планируете?
              0
              Вопрос автору и тем, кто «в теме». Как при такой сборке происходит процесс разработки, а конкретно поиск ошибок в коде?

              Only users with full accounts can post comments. Log in, please.