Введение
Разработка под Siebel имеет свои отличительные черты. В её основе лежит конфигурирование объектов, и автоматизация бизнес процессов c их использованием, как из кубиков, использование справочников особых значений. Возможность написания скриптов присутствует, но не занимает доминирующее положение. Все изменения производятся через IDE Siebel Tools, либо в интерфейсе приложения. Особенностей много, но ничто человеческое Siebel не чуждо, и в том числе проблема переноса изменений с dev контура на другие среды. В этой статье мы хотели бы рассказать о том, как работает наш ci/cd конвейер.
Авторы материала Horkin и Mryavka
RosbankSiebelTeam
Проблематика
Стоит начать с того, что изначально процесс переноса изменений состоял только из инструментов Siebel. После того, как разработчик внес изменение в объект, он должен вручную его экспортировать и положить в папку со своей задачей. При этом нельзя экспортировать только ту часть, которая была изменена, необходимо выгружать объект целиком. А решение задачи, вроде формирования PIN-кода для карты, или списания комиссии за справку, состоит из изменений большого количества таких объектов. При этом IDE не отслеживало список изменений и его приходилось вести вручную. Кстати, такие объекты хранятся в репозитории Siebel, и потому называются repo объектами. К этому добавляется то, что некоторые объекты имеют свои характерные особенности, например, Workflow-процессы (WF) нужно активировать, и чтобы изменения применились и работали, нужно написать инструкцию для администратора, и указать, какой именно процесс нужно активировать. Также нужно выгрузить справочники, которые содержат определенные значения бизнес логики, например, типы банковских счетов и их коды. Если справочник был изменен, например, появился новый тип счета, необходимо его также добавить в поставку. (Такие справочники экспортируются с помощью инструмента Siebel Application Deployment Manager и называются ADM объектами).
Скорее всего, если читатель не знаком с Siebel, то уже загружен новой инфой, но стоит сказать, что и это еще не все. Также есть элементы кастомизации интерфейса, скрипты БД и некоторые конфигурации, которые требует ручных действий. Все это также необходимо выгружать отдельно и указывать в инструкции.
В итоге, когда собирается релиз, который включает в себя большое количество задач от разных команд, то возникают проблемы: долгое формирование поставок, длительная установка, большое количество ошибок человеческого фактора. Администраторы загружены, а разработчики нервничают. В общем, такой подход вызывал заслуженное недовольство, и требовал преобразований. Так и началась работа над ci/cd конвейером.
Инструменты
Для корректной работы конвейера и коммуникации с участниками процесса были выбраны следующие инструменты:
• JIRA – используется для ведения задач для поставки; Частично используется для коммуникации: разработчики уведомляются о проблемах в сборке, заказчики уведомляются о завершении установки (посредствам комментариев и изменении статусов задач). Так же Jira используется для ведения истории поставок – в задачах отмечается, в рамках каких поставок была произведена установка на наши стенды.
• RocketSiebel (RS) – система контроля версий Siebel. В ней происходит версионирование стендов, разработчики размечают изменения в рамках задач, а конвейер – собирает поставку на требуемую среду.
• Jenkins – оркестратор конвейера. Занимается упорядочиванием действий конвейера, сигнализирует о наличиях ошибок.
• Ansible – “руки” нашего конвейера. При помощи скриптов, написанных на Python и PowerShell, выполняет сборку и установку поставки на стенды Siebel.
• Bitbucket – на данный момент исполняет только роль хранилища исходного кода конвейера. В будущем планируется использоваться для передачи ADM, неверсионируемых в RocketSiebel, и файлов Web-серверов.
• нативные инструменты Siebel :)
Описание работы
На текущий момент в Росбанке используется Siebel CRM Innovation Pack 20.5. При разработке функционала (в рамках требований задач Jira) разработчики вносят изменения на dev-стенде. Все эти изменения подтягивает в себя RocketSiebel и позволяет использовать эти изменения для сборки поставки и их передачи по средам. По завершении задачи разработчик размечает свои изменения в Task и называет ключом задачи Jira (чтобы в дальнейшем он мог быть использован при работе конвейера).
Рисунок 1. Тикет в JIRA
По расписанию (в 12:00 и 17:00 для ТЕСТ и в 14:00 для СЕРТ) конвейер начинает работу. Первым шагом он скачивает актуальные версии скриптов установки из Bitbucket. Затем конвейер выгружает по фильтрам Jira задачи для поставки (для ТЕСТ и СЕРТ отдельный фильтр), формирует патч для требуемого стенда в RockerSiebel. Если по какой-то причине по задаче нет Task'а – конвейер её просто пропускает.
Рисунок 2. Таск в RocketSiebel
После сборки конвейер производит проверку патча на наличие конфликтов. Если таковые имеются – идёт оповещение разработчиков через комментарий в Jira и сообщение в Telegram. Для решения конфликтов разработчикам даётся время на их исправление (по умолчанию – 1 час), если конфликты решены не будут – задача исключается из поставки.
При отсутствии конфликтов конвейер продолжает свою работу.
Рисунок 3. Оповещение о конфликте
По завершении работы с конфликтами конвейер делает Merge патча и формирует итоговую поставку для стенда Siebel CRM. После чего начинается процесс установки патча.
Следующим шагом конвейер скачивает и распаковывает архив с поставкой на Windows-сервере, откуда будет производиться установка на стенд. Обязательное условие – наличие на этом сервере подключения к БД Siebel CRM и Siebel Tools.
Рисунок 4. Пайплайн в Jenkins
Установка на требуемый стенд начинается с создания Workspace, в который будут импортироваться объекты. Имя воркспейса соответствует названию поставки в RocketSiebel (для удобства разбора проблем с поставкой).
По нашему опыту работы с IP 20.5 есть определённые проблемы с импортом Workflow процессов, в связи с этим после создания Workspace конвейер переименует WF на стенде по списку объектов поставки, во избежание проблем после установки. SQL скрипт для переименования формируется при помощи java-метода, который вызывается Ansible’ом в БД Siebel.
Затем конвейер блокирует все проекты и происходит импорт объектов из поставки. Далее формируется и применяется скрипт изменения объектов БД (Apply DDL). После происходит инкрементальная компиляция таблиц в Runtime-репозиторий. Список таблиц для компиляции формируется на основании объектов в поставке.
Следующим шагом происходит Checkpoint и Deliver Workspace в Main (применяются изменения к Runtime-репозиторию). При помощи Soap-сервиса отправляется запрос в Siebel с названиями Workflow процессов для их активации.
Последним шагом в установке является заливка справочников ADM. Импорт производится при помощи вызова утилиты RocketSiebel.
По завершении установки конвейер делает оповещения в задачах JIRA из поставки о завершении установки:
- Указывается имя поставки, в рамках которой производилась установка;
- Публикуется комментарий о том, что поставка завершена;
- Меняется статус, сигнализирующий о том, что можно начинать тестирование.
Дополнительно идёт оповещение разработчиков в Telegram-канале о завершении установки (и наличии возможных ошибок). Дополнительно, информация об установке и лог заливки объектов дублируются в почте.
Рисунок 5. Оповещение об успешной установке
Ближайшие планы
Хотя все справочники версионируются в RocketSiebel, есть печатные формы (ПФ), которые тоже относятся к АДМ объектам, но стоят особняком. На данный момент RS их не версионирует, а в задачах они встречаются часто. Чтобы встроить деплой ПФ в пайплайн, на стороне Siebel сделали отдельный веб-сервис, а сами формы планируем передавать через BitBucket.
Кроме этого, на данной момент конвейер не содержит шаг с рестартом сервера, а не смотря на введения нового Innovation Pack, рестарт часто требуется, так как некоторые серверные компоненты, например, EAIObjMgr не подтягивают изменения из рантайм репозитория без рестарта.
Заключение
На данный момент разработчики тратят гораздо меньше времени на формирование поставок по своим задачам. Администраторы тратят меньше времени на установку изменений на целевые среды, а некоторых кейсах даже не привлекаются к установке. Существенно сократилось время поставок на непроизводственные контуры и теперь мы выносим изменения в среду тестирования 2 раза в день, а препродакшена 1 раз. Косвенно это повлияло и на количество багов на продакшене, которых заметно сократилось.
Несмотря на то, что получилось достичь определенных результатов, мы планируем и дальше развивать процесс автоматизации установки изменений, сокращать время поставок, добавлять новые фишки и удобства.
