Привет! Хорошо налаженным CI/CD сложно кого-то удивить, потому что чаще всего это происходит в классических IT-компаниях. А в них не бывает таких жестких ограничений в плане информационной безопасности.
Как вы понимаете, у нас в СИБУРе с этим дела обстоят немного иначе. Но мы все равно осилили развернуть полноценный CI/CD в рамках целых предприятий — теперь в пару кликов мы можем разворачивать новые релизы ПО на всех наших заводах. В этом посте я расскажу, что именно мы сделали.
Наш продукт называется “IoT Платформа СИБУР” и он распределенный: центральный репозиторий с образами нашего софта лежит на серверах в корпоративном центре, а сама платформа устанавливается на сервер каждого завода. И делалось это обычно заботливыми руками отдельно взятых специалистов. Мы решили автоматизировать процесс обновлений версий платформы на каждом заводе, и вышло так, что мы стали первым продуктом в цифровизации СИБУРа, который автоматизировал деплой на заводы (из единого репозитория в корпоративном центре).
Релизы: до и после
Итак, давайте с базы. Continuous Integration (CI) – это процесс сборки релизов. Скажем, разработчики создали какую-то новую функцию и добавляют все свои изменения в ветки нашего продукта в GitLab. Затем, когда все изменения добавлены в ветку очередного релиза, начинается процесс сборки CI. К каждому релизу прикрепляется определенный номер, и главная проблема состоит в том, чтобы его доставить до площадки.
В обычных компаниях для Continuous Delivery (CD) есть отдельный репозиторий, где лежит devstack продуктов, все платформы. Оттуда вносят изменения, и через CD все это разливается на stage, test-server и prod.
В СИБУРе из-за характера деятельности своя атмосфера, и процесс CI/CD в привычном смысле использовался только для программного обеспечения в Корпоративном Центре. Но мы сделали его доступным и для распределенной системы, когда репозиторий с кодом лежит в Корпоративном Центре, а релизы разливаются на заводы.
Поэтому нам нужно было к этому CI аккуратно прицепить CD-процесс, чтобы ничего не поломалось. По сути мы совместили вместе три среды: среду КЦ, среду площадки и среду ноутбука разработчика. Также, в отличие от других компаний, мы поставляем нашу платформу прямо из репозитория, разработчик может в любой момент изменить какую-то строчку кода, и это буквально через полчаса будет работать на площадке.
Наша платформа сейчас работает в продуктивном контуре на четырех предприятиях:
ЗапСибНефтехим
ТомскНефтехим
Воронежсинтезкаучук
Кстово.
В этом году к ним добавятся еще пять платформ на других заводах, в целевом виде таких платформ может быть около двадцати. Мы очень часто релизим бэкенд, фронтенд и дашборд, для четырех платформ таким образом набегает уже двенадцать действий. А в ближайшем будущем, за счет роста количества продуктов в рамках платформы и количества самих платформ на заводах, этих действий стало бы уже больше пятидесяти. До автоматизации CD нужно было зайти на каждую площадку, на каждый сервер и менять там руками файл, что не очень удобно. Поэтому благодаря нашему решению разработчики экономят колоссальное количество времени.
В целом такой подход применяется и в других компаниях, но у всех свои требования к информационной безопасности, своя архитектура корпоративной сети. Поэтому каждая компания прорабатывает это под себя. Данное решение мы спроектировали именно в концепции СИБУРа с учетом наших требований.
Ход процесса глазами разработчика
Разработчик пишет код и отправляет его на GitLab на какую-то свою ветку, после чего ему нужно объединить это все с основной веткой.
Здесь происходит проверка кода, после которой создается новая версия продукта с прикрепленной версией релиза. Затем у разработчика в GitLab появляется кнопка “Отправить релиз на площадку №1”, после нажатия на которую срабатывает GitLab Runner, который подключается к этому репозиторию, копирует код, подключается к определенному серверу на площадке, подставляет в файл с конфигурацией новую версию релиза и запускает файл, отвечающий за раскатку на сервера платформы.
Этот файл сравнивает версии образов с данными в файле конфигурации, запускает новые образы в Docker. После этих действий разработчик видит у себя зеленую галочку и может наблюдать за состоянием рабочей платформы, причем релиз можно залить на каждую площадку отдельно.
Всё было бы совсем просто, если бы не…
Административная часть. Всегда необходимо грамотно описывать бизнес-потребности, объяснять, для чего это нужно, и согласовать все изменения.
Мультисервисная архитектура. Наша платформа состоит из множества сервисов, каждый из которых живет своей жизнью.
Объединение процесса CI/CD в один. Разработчику теперь не надо отдельно собирать и отдельно доставлять релиз на площадки, он все делает сразу. Мы реализовали целевое видение CI/CD так, как это задумано в этой методологии. Очень многие ограничиваются автоматизацией CI, так как на этапе CI проходит автоматическая проверка на уязвимости.
Ценность полученного результата заключается в том, что мы полностью реализовали эту концепцию в достаточно сложной архитектуре распределенной системы, которая устанавливается на сервера на разных площадках.
Что дальше
На очереди с CD у нас проект интеллектуального видеонаблюдения. Да и в целом — мы активно протаптываем эту тропинку для остальных продуктов: уже проработали вопросы с информационной безопасностью, с технической реализацией, отладили эту схему, и теперь остальные продукты могут пользоваться нашими практиками.
В масштабах компании это даст большую экономию времени всех разработчиков.
А экономию времени сложно переоценить.