Связаться по:
vkarabedyants Telegram Viber

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Автоматизация процесса деплоя

5/5 - (1 голос)

Потенциал для автоматизации: избавляемся от рутинных процессов

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

Основная идея автоматизации – непрерывная интеграция (Continuous Integration), объединяющая процессы тестирования, сборки и дополнительных проверок, а также непрерывная доставка (Continuous Delivery). Это то, что известно всем как CI/CD Pipeline девопс задача.

автоматизация деплоя

Что под капотом автоматизации

В CI/CD Pipeline разработка большинства современного ПО подразумевает итеративность:

> Идея -> Написание кода -> Тестирование -> Релиз

Этот процесс включает в себя значительное количество этапов, которые нужно повторять при прохождении каждого цикла. Автоматизировать этот процесс – одна из ключевых задач, когда проект расширяется. Это может быть связано как с увеличением команды разработчиков, так и с такими техническими особенностями, как рост количества сервисов в проекте или необходимость в параллельной разработке.

Триггеры процессов.

Любые изменения в нашей инфраструктуре сопровождаются изменениями кода. То есть потенциальный разработчик берет последнюю версию программы, source code, меняет что-то, комит, заливает свой код на GitHub. Для нас это основной триггер для всех процессов автоматизации.

1. Пишем код

По сути это этап генерации source code, который тесно связан с контролем версий, и здесь на помощь приходит Git. Используем GitHub для менеджмента репозиториев. Во многих из них разработка ведется параллельно и независимо, то есть разными командами.

Настраивая свой CI/CD Pipeline, установили контракт для разработчиков при написании кода и заливке его в GitHub:

1. Каждая созданная ветвь (Git) должна иметь в названии номер JIRA тикета. Так легко можно понять, к какой задаче относятся изменения в этой ветке. Эта информация также используется в следующих этапах нашего пайплайна (версионирование, деплой), поскольку каждая наша ветвь (тикет) развертывается как отдельная копия программы в отдельном окружении. Это позволяет вести действительно параллельную разработку множества фич одновременно и дать разработчикам свободу и независимость друг от друга.

2. Каждый комит должен соответствовать стандарту Conventional Commits . Это облегчает создание Changelog, а также позволяет автоматически определять новую версию программы (о версии подробнее чуть позже)

2. С source code в артефакт

Этап сборки программы включает все манипуляции для преобразования source code в артефакт:

  • Линтинг и статический анализ кода – проверяем код на соответствие нормам и внутренним правилам команды.
  • Сборка (компиляция/контейнеризация) – здесь из исходного кода формируется единственный файл, которому будет назначена версия (процесс версионирования). После этого он попадет в реестр артефактов, то есть зарелизится.
  • Тестирование – в зависимости от размера программы, здесь могут запускаться как юнит, так и в некоторых случаях интеграционные тесты.

Здесь в дело вступает GitHub Actions, как наш основной CI инструмент для автоматизации.

3. SemVer для всех артефактов: получаем валидную версию

На этом этапе артефакта назначается версия. Используем SemVer для всех типов наших артефактов. В этом деле нам помогает Semantic Release и  Conventional Commits. Они позволяют в несколько строк кода решить задачу версионирования и получить на выходе актуальную и валидную версию.

Как вы помните, каждая наша git-ветка развертывается как отдельная копия программы и имеет в своем имени номер JIRA тикета. Этот номер используется как пререлиз токена при формировании версии, а также как сабдомен при развертывании программы.

4. Выпускаем релиз в свет

Здесь мы загружаем наш артефакт в соответствующий реестр. У нас это:

Docker Image → Amazon ECR
Helm Chart → ChartMuseum
NPM Package → GitHub Packages

5. Деплой: следим за правильностью работы

Происходит развертывание программы и в дело вступает ArgoCD . Работает это так:

ArgoCD следит за изменениями в одном из наших git-репозиториев (argo) и ждет, когда там появится или изменится Helm Chart (конфигурация) с описанием всех зависимостей и их версий (то, что было сформировано на этапе релиза), необходимых в этом окружении. В этой репозитории также живет базовый шаблон такого чарта с дефолтными настройками и версиями, необходимыми для запуска базовой версии программы.

Здесь также хранится Triggerable GH Action, который можно запустить с использованием обычного curl. Ему можно передать названия и версии зависимостей, которые вы хотите переопределить в шаблоне, после чего небольшой скрипт измерит базовый шаблон (chart.yml) с переданными вами версиями, создаст новый Helm Chart именно под ваши потребности в папке с именем того же JIRA тикета . Его подхватит ArgoCD и самостоятельно задеплоит в Kubernetes.

За всем вы можете наблюдать с веб-консоли ArgoCD в приятном графическом интерфейсе, просматривать логи при необходимости и следить за правильностью работы вашей версии программы.

6. Переходим к тестированию

После полноценного развертывания программы или ее копии у нас производится запуск E2E тестов. Мы используем Cypress, поэтому просто запускаем наши тесты в GH Actions через Triggerable Pipeline (вызов curl из k8s джоба). А также автоматически прикрепляем ссылку на развернутое приложение к JIRA Тикету, чтобы мануальные тестировщики быстро могли приступить к тестированию.

После всех проверок и апрувов код мержится в master (production ready ветвь). И весь процесс происходит еще раз, однако теперь доставка осуществляется уже в продакшне, после чего результат работы может наблюдать конечный пользователь.

В общем, весь пайплайн занимает от 3 до 7 минут в среднем. А количество развернутых копий программы напрямую зависит от количества разработчиков и задач на борде. В общей сложности у нас одновременно запущено около 80 копий. Приложения, не переживающие редеплой в течение семи дней, автоматически умирают, однако в любой момент могут быть перезапущены заново.

Масштабирование и микросервисная архитектура: суммируем результаты

При этом подход непрерывной доставки важен для любой команды. Если пишешь под Android, будут свои нюансы, например, отправляешь все в Play Market, а мы – на сервер. Однако суть одна. Мы, как команда Back-end Core, пытались задать общий вектор именно нашей микросервисной архитектуры. Ведь сейчас мы в процессе перехода от монолитной архитектуры, которая у нас была в прошлом, к независимой интеграции и доставке микросервисной архитектуры.

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.