В Сети много рецептов приготовления CI/CD для решения различных проблем и организации процессов под определённые нужды. В этой статье мы опишем ещё один, суть которого - приготовить процесс, максимально близкий к классическому подходу, несмотря на то что предназначен он для разработки КХД, и решить проблему организации работы большой команды
Цели
Технологический стек
В итоге была выбрана такая конфигурация:
GitLab мы выбрали в качестве репозитория. Oracle - в качестве СУБД, SonarQube - это статический анализатор кода, Ansible - это менеджер конфигураций, позволяющий распараллелить операции на множество инстансов. Nexus Repository - это хранилище артефактов. И наконец, Jenkins всем этим управляет.
Прежде чем начинать работать над автоматизацией, необходимо все патчи привести к единому формату. Основными требованиями являются:
Continuous integration
Со стеком определились, патчи привели к одному виду. Теперь можно браться за автоматизацию.
Эта часть процесса состоит из двух этапов: проверка и установка. На каждый этап создан отдельный pipeline в Jenkins. Проверочный pipeline запускается по триггеру создания Merge Request в GitLab, забирает ветку, которую хотят объединить, и пытается установить патч. Перед установкой в БД создаётся restore point, это снимок БД, к которому она возвращается при возникновении ошибки при установке патча. Roll back выполняется в автоматическом режиме после каждой неудачной установки патча.
Установка может производиться как на один, так и на несколько инстансов. Это происходит параллельно средствами Ansible. Само выполнение скриптов происходит средствами утилиты sqlplus.
На этапе проверки патча проходит контроль исходного кода средствами SonarQube, и если патч установился без ошибок, то кодревьювер получает уведомление о том, что патч валиден и может отправляться в ветку develop.
Следующий этап – установка. Когда мы поняли, что патч готов к формированию и передаче в функциональное тестирование, нужно изменения в этом патче окончательно установить в контуре CI и подготовить к установке на другие среды.
На этом этапе триггером служит исполнение Merge Request и процесс проходит уже без каких-либо проверок. Формируется zip-архив и отправляется в хранилище артефактов Nexus.
Система версионирования
Для работы этого процесса нам нужно в момент установки понимать, в каком состоянии находится контур, какие объекты в нём есть, а какие необходимо установить. Патч может содержать представление или функцию, которая ссылается на таблицу, которая создаётся в другом патче, и перед установкой нам нужно проверить, установлен ли он.
Так как зависимости распространяются на весь контур, то и проверять зависимости нужно во всём контуре.
Мы после установки каждого патча делаем запись в историческую таблицу. Благодаря такому простому решению мы знаем, какие патчи установлены в каждый контур.
Continuous Delivery
Вот мы решили ещё две проблемы: исключили разработчика из процесса формирования патчей и сделали систему, в которой процесс сможет контролировать выполнение зависимостей патчей. Теперь необходимо автоматизировать передачу этого патча на дальнейшие среды.
Сейчас разработанный нами функционал лежит в хранилище артефактов Nexus. Нам надо толкнуть его дальше в контур FT. У каждого патча там есть метка с timestamp, по которой мы определяем самую свежую версию патча. Процесс происходит проще и быстрее, чем в CI, отличается источник, приёмник и нет многих проверок.
После тестирования патч попадает либо в реестр готовых к передаче заказчику, либо в начало нашего процесса на доработку.
Уведомления через Telegram
Вот уже работа идёт гораздо быстрее, патчи гуляют по контурам с невероятной скоростью, команда совсем не тратит на это время и занимается своими делами, а именно перезаписывает функционал друг друга, создаёт конфликты в гите и спамит кодревьювера просьбами смёржить их изменения.
Вышеперечисленные проблемы приводили к тому, что пропадали часы работы разработчиков при перезаписи, девопс тратил время на решение конфликтов в гите, а кодревьювер искал среди merge requests необходимый запрос для слияния.
Самым простым решением будет сделать оповещение разработчиков и кодревьювера через почту. Мы сделали. Эти письма в лучшем случае игнорировались, а в худшем отправлялись прямиком в корзину бездушными правилами Outlook. Все продолжали использовать Телеграм как предмет координации. Тогда мы решили их там информировать.
Телеграмм-бот нам показался отличным решением этой проблемы, хотя в действительности он таковым стал не сразу. Его разработка также была связана с трудностями:
В первой версии бот просто информировал разработчиков о результатах сборки. Она просуществовала до тех пор, пока не потребовалось организовать очередь для работы над одной веткой.
Так появилась вторая версия, которая была привязана к базе данных с участниками команды и могла самостоятельно актуализировать ветки из GitLab для организации очереди к ней.
Принцип взаимодействия с ботом был предельно прост. Разработчик обращается к боту, выбирая из списка номер ветки, которую хочет взять в работу. А бот ему отвечает, работает над ней сейчас кто-то или нет. Если нет, то он предлагает взять её в работу, а если она занята, то предлагает встать в очередь (ожидание в очереди редко превышало 30 минут). Бот уведомит, когда ветка освободится.
Что касается безопасности, то мы старались никаких конкретных данных не вставлять в сообщения. Они носили исключительно технических характер, да и сам бот не особо разговорчивый. Ему разрешено отвечать только членам команды разработки.
Итог
Это решение помогло разработчикам заняться разработкой, тестировщикам заняться тестированием, кодревьюверу проводить ревью кода и следить за его качеством. То есть убрали человека из процесса поставки кода, что серьёзно сократило количество ошибок.
Благодаря системе версионирования всегда понятно, в каком состоянии находится тот или иной контур, но человеку это даже не так важно. Если он хочет привести контур к определённому виду, то ему будет понятно, что нужно для этого установить.
Так как установка на контуры одинакова, то при добавлении новых эта система легко масштабируется. Меняется просто контур для установки.
У нас больше нет конфликтов в гите. Все разработчики используют Телеграм и не препятствуют работе друг друга.
Ускорили доставку функционала, а значит, сократили time to market благодаря раннему выявлению ошибок.
habr.com
Цели
- Избавить разработчиков от бесконечного переноса функционала с одной среды на другую.
- Создать систему версионирования для решения проблемы зависимости в разработке КХД.
- Процесс должен соответствовать требованиям ACID, т. е. неисправный патч не должен сломать всё хранилище.
- Стандартизация разработки.
- Организация хранилища патчей для Сontinuous Delivery.
- Организация работы большой команды.
Технологический стек
В итоге была выбрана такая конфигурация:
GitLab мы выбрали в качестве репозитория. Oracle - в качестве СУБД, SonarQube - это статический анализатор кода, Ansible - это менеджер конфигураций, позволяющий распараллелить операции на множество инстансов. Nexus Repository - это хранилище артефактов. И наконец, Jenkins всем этим управляет.
Прежде чем начинать работать над автоматизацией, необходимо все патчи привести к единому формату. Основными требованиями являются:
- Жёсткая структура директорий. Разделение на различные среды, схемы и типы объектов в них.
- Makefile с указанием инстанса для установки и пути к скрипту.
- Файл с зависимостями для каждого патча в виде списка других патчей, от которых зависит текущий.
- Bash-скрипт для установки патча на любую среду. Этот скрипт делает snapshot баз данных, которые затрагиваются патчем, через sqlplus выполняет все скрипты, которые указаны в makefile, и если какой-то из них выполнялся с ошибкой, то возвращал базу данных в состояние до установки.
- И обязательный для заполнения release_notes.
- DEV – в этом контуре разрабатываются патчи.
- CI – этот контур служит для проверки патчей на валидность.
- TEST – тут происходит функциональное тестирование.
- PrePROD – контур, в котором заказчик проводит собственное тестирование перед отправкой на прод.
- PROD – продуктивная среда.
- HOTFIX – полная копия прода для исправления критических ошибок.
Continuous integration
Со стеком определились, патчи привели к одному виду. Теперь можно браться за автоматизацию.
Эта часть процесса состоит из двух этапов: проверка и установка. На каждый этап создан отдельный pipeline в Jenkins. Проверочный pipeline запускается по триггеру создания Merge Request в GitLab, забирает ветку, которую хотят объединить, и пытается установить патч. Перед установкой в БД создаётся restore point, это снимок БД, к которому она возвращается при возникновении ошибки при установке патча. Roll back выполняется в автоматическом режиме после каждой неудачной установки патча.
Установка может производиться как на один, так и на несколько инстансов. Это происходит параллельно средствами Ansible. Само выполнение скриптов происходит средствами утилиты sqlplus.
На этапе проверки патча проходит контроль исходного кода средствами SonarQube, и если патч установился без ошибок, то кодревьювер получает уведомление о том, что патч валиден и может отправляться в ветку develop.
Следующий этап – установка. Когда мы поняли, что патч готов к формированию и передаче в функциональное тестирование, нужно изменения в этом патче окончательно установить в контуре CI и подготовить к установке на другие среды.
На этом этапе триггером служит исполнение Merge Request и процесс проходит уже без каких-либо проверок. Формируется zip-архив и отправляется в хранилище артефактов Nexus.
Система версионирования
Для работы этого процесса нам нужно в момент установки понимать, в каком состоянии находится контур, какие объекты в нём есть, а какие необходимо установить. Патч может содержать представление или функцию, которая ссылается на таблицу, которая создаётся в другом патче, и перед установкой нам нужно проверить, установлен ли он.
Так как зависимости распространяются на весь контур, то и проверять зависимости нужно во всём контуре.
Мы после установки каждого патча делаем запись в историческую таблицу. Благодаря такому простому решению мы знаем, какие патчи установлены в каждый контур.
Continuous Delivery
Вот мы решили ещё две проблемы: исключили разработчика из процесса формирования патчей и сделали систему, в которой процесс сможет контролировать выполнение зависимостей патчей. Теперь необходимо автоматизировать передачу этого патча на дальнейшие среды.
Сейчас разработанный нами функционал лежит в хранилище артефактов Nexus. Нам надо толкнуть его дальше в контур FT. У каждого патча там есть метка с timestamp, по которой мы определяем самую свежую версию патча. Процесс происходит проще и быстрее, чем в CI, отличается источник, приёмник и нет многих проверок.
После тестирования патч попадает либо в реестр готовых к передаче заказчику, либо в начало нашего процесса на доработку.
Уведомления через Telegram
Вот уже работа идёт гораздо быстрее, патчи гуляют по контурам с невероятной скоростью, команда совсем не тратит на это время и занимается своими делами, а именно перезаписывает функционал друг друга, создаёт конфликты в гите и спамит кодревьювера просьбами смёржить их изменения.
Вышеперечисленные проблемы приводили к тому, что пропадали часы работы разработчиков при перезаписи, девопс тратил время на решение конфликтов в гите, а кодревьювер искал среди merge requests необходимый запрос для слияния.
Самым простым решением будет сделать оповещение разработчиков и кодревьювера через почту. Мы сделали. Эти письма в лучшем случае игнорировались, а в худшем отправлялись прямиком в корзину бездушными правилами Outlook. Все продолжали использовать Телеграм как предмет координации. Тогда мы решили их там информировать.
Телеграмм-бот нам показался отличным решением этой проблемы, хотя в действительности он таковым стал не сразу. Его разработка также была связана с трудностями:
- Во-первых, весь стек был в корпоративной сети. Нам повезло, что доступ в интернет там был.
- Во-вторых, в то время Телеграм был запрещённым мессенджером.
В первой версии бот просто информировал разработчиков о результатах сборки. Она просуществовала до тех пор, пока не потребовалось организовать очередь для работы над одной веткой.
Так появилась вторая версия, которая была привязана к базе данных с участниками команды и могла самостоятельно актуализировать ветки из GitLab для организации очереди к ней.
Принцип взаимодействия с ботом был предельно прост. Разработчик обращается к боту, выбирая из списка номер ветки, которую хочет взять в работу. А бот ему отвечает, работает над ней сейчас кто-то или нет. Если нет, то он предлагает взять её в работу, а если она занята, то предлагает встать в очередь (ожидание в очереди редко превышало 30 минут). Бот уведомит, когда ветка освободится.
Что касается безопасности, то мы старались никаких конкретных данных не вставлять в сообщения. Они носили исключительно технических характер, да и сам бот не особо разговорчивый. Ему разрешено отвечать только членам команды разработки.
Итог
Это решение помогло разработчикам заняться разработкой, тестировщикам заняться тестированием, кодревьюверу проводить ревью кода и следить за его качеством. То есть убрали человека из процесса поставки кода, что серьёзно сократило количество ошибок.
Благодаря системе версионирования всегда понятно, в каком состоянии находится тот или иной контур, но человеку это даже не так важно. Если он хочет привести контур к определённому виду, то ему будет понятно, что нужно для этого установить.
Так как установка на контуры одинакова, то при добавлении новых эта система легко масштабируется. Меняется просто контур для установки.
У нас больше нет конфликтов в гите. Все разработчики используют Телеграм и не препятствуют работе друг друга.
Ускорили доставку функционала, а значит, сократили time to market благодаря раннему выявлению ошибок.
Реализация CI/CD для корпоративных хранилищ данных
В Сети много рецептов приготовления CI/CD для решения различных проблем и организации процессов под определённые нужды. В этой статье мы опишем ещё один, суть которого - приготовить процесс,...
habr.com