Настройка CI/CD и автоматизация деплоя

Настраиваю CI/CD для небольших команд разработки: сборка, тесты, проверка на уязвимости и выкладка на сервер или в Kubernetes после коммита в Git. GitLab CI, GitHub Actions, ArgoCD.

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

  • GitLab CI, GitHub Actions
  • Сервер или Kubernetes
  • Откат одной командой

Что входит в настройку CI/CD

Можно заказать пайплайн для одного сервиса или выстроить выкладку для всего проекта.

Сборка

Каждый коммит собирается одинаково, без «у меня на ноутбуке работает».

  • ✓Docker-образы с кешем слоёв
  • ✓версия по тегу или хешу коммита
  • ✓хранение образов в Container Registry
  • ✓сборка только изменившихся сервисов

Тесты и проверки

Ошибку дешевле поймать до выкладки, чем после.

  • ✓запуск тестов и линтеров
  • ✓проверка миграций базы
  • ✓запрет слияния, если тесты упали
  • ✓результаты прямо в merge request

Безопасность

Уязвимая библиотека или забытый пароль в коде не должны попасть в продакшен.

  • ✓сканирование образов в Trivy
  • ✓поиск секретов в коде
  • ✓SonarQube для качества кода
  • ✓секреты в Vault или переменных CI, а не в репозитории

Деплой на сервер

Для проектов без Kubernetes: выкладка на VPS или выделенный сервер.

  • ✓Docker Compose или systemd
  • ✓выкладка без простоя
  • ✓миграции базы в правильном порядке
  • ✓проверка, что сервис поднялся

Деплой в Kubernetes

Выкладка в кластер через Helm или по модели GitOps.

  • ✓Helm-чарты для сервисов
  • ✓ArgoCD: в кластере ровно то, что в Git
  • ✓постепенная выкладка с проверкой
  • ✓отдельные namespace или кластеры для окружений

Окружения

Новая версия сначала проходит проверку и только потом доходит до клиентов.

  • ✓staging и production
  • ✓временные окружения для веток
  • ✓ручное подтверждение выкладки в production
  • ✓свои настройки и секреты у каждого окружения

Откат

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

  • ✓возврат прошлой версии одной командой
  • ✓хранение предыдущих образов
  • ✓автоматический откат, если проверки не прошли
  • ✓история: кто, что и когда выкатил

Раннеры и скорость

Медленный пайплайн разработчики начинают обходить.

  • ✓свои раннеры вместо платных минут
  • ✓кеш зависимостей
  • ✓параллельные задачи
  • ✓уведомления о релизах в Telegram

Стоимость настройки CI/CD

Объём работ оцениваю в часах до начала и согласую с вами.

ФорматЦенаЧто входит
Аудит пайплайнаот 10 000 ₽скорость сборки, секреты, ручные шаги, откат; отчёт с планом исправлений
Настройка3 000 ₽/чассборка, тесты, проверка на уязвимости, деплой; оценка до начала работ
Сопровождение20 000 ₽/месраннеры, обновления, разбор упавших сборок, помощь команде с релизами

Примеры расчёта

ЗадачаОценка
Пайплайн для одного сервиса: сборка образа, тесты, деплой на сервер4-8 часов
Окружения staging и production с подтверждением выкладки4-6 часов
Проверка образов и зависимостей на уязвимости2-3 часа
Ускорение медленной сборки: кеш, параллельные задачи2-6 часов

Как проходит настройка

  1. 1

    Как релизят сейчас

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

  2. 2

    План пайплайна

    Предлагаю этапы и окружения под ваш проект. Одному сервису на VPS не нужен ArgoCD.

  3. 3

    Первый сервис

    Настраиваю пайплайн на одном сервисе и вместе с командой провожу первый релиз.

  4. 4

    Остальные сервисы

    Переношу схему на остальные сервисы через общие шаблоны, чтобы не копировать конфигурацию.

  5. 5

    Передача

    Описываю, как выкатить, откатить и добавить новый сервис. Дальше команда справляется сама.

С чем приходят

Как выкладывать, знает один человек

Релиз - набор команд в голове одного разработчика. Он в отпуске, и релиз ждёт.

Выкладывать в пятницу страшно

Каждый релиз - риск, откат занимает час. С быстрым откатом выкладывать можно в любой день.

Пайплайн идёт 40 минут

Сборка без кеша, тесты по очереди. Обычно время сокращается в разы без замены инструментов.

Пароли лежат в репозитории

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

GitLab CI, GitHub Actions или Woodpecker

Выбор обычно определяется тем, где уже лежит код:

GitLab CIGitHub ActionsWoodpecker CI
Где работаетgitlab.com или свой серверgithub.com, можно свои раннерысвой сервер, вместе с Forgejo или Gitea
Сильная сторонакод, CI и registry в одном местеготовые действия почти на любую задачулёгкий, хватает небольшого VPS
Свой серверда, есть бесплатная версиянет, только раннерыда, открытый код
Когда выбиратьвсё нужно держать у себякод уже на GitHubGitLab слишком тяжёл для команды

Логика пайплайна переносится между системами, меняется синтаксис. Если нужно российское ПО, есть GitFlic: он устроен похоже на GitLab и тоже умеет CI.

Из чего состоит пайплайн

Типичный путь изменения от коммита до продакшена:

  1. Разработчик открывает merge request, запускаются линтеры и тесты.
  2. После слияния собирается Docker-образ с версией из хеша коммита.
  3. Образ проверяется на известные уязвимости: trivy image.
  4. Новая версия автоматически выкатывается на staging.
  5. После проверки кто-то из команды подтверждает выкладку в production.
  6. Если после выкладки сервис не отвечает, пайплайн возвращает прошлую версию.

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

Технологии

CI/CD
GitLab CIGitHub ActionsWoodpecker CI
Деплой
ArgoCDHelmDocker ComposeAnsible
Безопасность
TrivySonarQubeVault
Инфраструктура
DockerKubernetesK3sTerraform

Примеры работ

ML-платформа: выкладка в закрытый контур

Обновления сервисов нужно было доставлять не только в облако, но и во внутреннюю сеть заказчика, закрытую снаружи.

Настроил сборку в GitLab CI, зеркалирование репозиториев в контур заказчика через VPN и автоматическую выкладку оттуда.

10+сервисов выходят без ручных шагов

Автономные тракторы: GitOps в AWS

Платформе управления флотом нужна была предсказуемая выкладка в кластер EKS.

Настроил сборку в CodeBuild и деплой через ArgoCD: в кластере работает ровно то, что описано в Git.

100+машин работают на этой платформе

Почему со мной удобно

Без лишнего

Не ставлю ArgoCD и пять окружений туда, где хватит одного пайплайна на 30 строк.

Был разработчиком

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

Всё в вашем репозитории

Пайплайны лежат рядом с кодом. Нет внешних сервисов, о которых знаю только я.

Российские облака

Настраиваю выкладку в Yandex Cloud и Selectel и раннеры на ваших серверах, если нужна независимость от зарубежных платформ.

Частые вопросы

Сколько стоит настройка CI/CD? +

Пайплайн для одного сервиса со сборкой, тестами и деплоем на сервер обычно занимает 4-8 часов, по 3 000 ₽/час. Аудит существующего пайплайна стоит от 10 000 ₽.

Что такое CI/CD простыми словами? +

CI - автоматическая сборка и проверка каждого изменения в коде. CD - автоматическая выкладка проверенной версии на сервер. Вместе они заменяют ручной релиз на слияние ветки или нажатие кнопки.

Нужен ли CI/CD маленькой команде? +

Да, если релизы выходят чаще раза в месяц. Даже одному разработчику автоматическая выкладка экономит время и убирает ошибки ручных команд.

Работаете с GitLab на нашем сервере? +

Да: gitlab.com или GitLab на вашем сервере, GitHub. Если код нужно держать у себя, подниму свой GitLab или лёгкую связку Forgejo и Woodpecker.

Как проверять образы на уязвимости? +

Trivy в пайплайне сверяет образ и зависимости с базой известных уязвимостей. Критичные находки останавливают выкладку, остальные попадают в отчёт.

Можно ли выкладывать без простоя? +

Да. В Kubernetes это постепенное обновление подов. На обычном сервере новая версия запускается рядом со старой, и трафик переключается, когда она готова.

Оставить заявку

Напишите, где лежит код, куда его выкладывают и как это происходит сейчас. Предложу пайплайн и оценю его в часах.

Смотрите также