Самый полный гайд по CI/CD: что это, как работает, примеры, инструменты, процессы, автоматизация

Современная разработка меняется быстрее, чем когда-либо. Выпуск новых версий, тестирование и доставка обновлений стали непрерывным процессом, где цена ошибки измеряется не днями, а минутами. Команды стремятся автоматизировать всё, что можно, чтобы не терять темп и качество.

На этом фоне появился подход CI/CD — система, которая превращает хаотичные этапы разработки в отлаженный поток. Он помогает объединить работу программистов, тестировщиков и DevOps-инженеров, убирает лишние ручные шаги и делает релизы предсказуемыми. В этой статье мы разберём, как работает CI/CD, какие процессы лежат в основе и как выстроить конвейер от идеи до готового продукта.

Основы CI/CD

Перед тем как разбирать инструменты и настройку, важно понять, из чего состоит сам подход. Если вкраце, то CI/CD описывает логику непрерывной разработки: путь кода от идеи до готового релиза, процессы, которые автоматизируются, и методы обеспечения стабильности при частых изменениях.

Что это такое

CI/CD (Continuous Integration/Continuous Deployment / Delivery) — совокупность практик, объединяющих непрерывную интеграцию и развертывание ПО. Она формирует управляемый поток разработки, в котором изменения кода автоматически тестируются, собираются и доставляются в рабочие среды без пауз между этапами.

Цель CI/CD — ускорить и автоматизировать выпуск обновлений, повысить производительность команд и сократить время от написания кода до его появления у пользователей. В отличие от традиционной модели, где обновления накапливались и выпускались пакетами, CI/CD обеспечивает плавный и непрерывный поток релизов, минимизируя задержки и упрощая контроль над процессом.

Расшифровка

CI/CD состоит из двух взаимосвязанных частей: CI (Continuous Integration) и CD (Continuous Deployment / Delivery). Вместе они формируют единый конвейер разработки и поставки ПО, в котором изменения кода проходят автоматическую проверку, тестирование и доставку пользователям.

CI (Continuous Integration, с англ. «непрерывная интеграция»). Код регулярно вносится в основную ветку проекта, и каждый коммит запускает автоматическую сборку и тестирование. Процессы совместной работы команды становятся прозрачными, стабильность кодовой базы поддерживается, а внедрение изменений упорядочено и предсказуемо.

CD (Continuous Deployment / Delivery, с англ. «непрерывное(ая) развертывание/доставка»). После успешного прохождения CI изменения автоматически/вручную разворачиваются в рабочем окружении. Пользователи получают обновления быстрее, сокращается простой сервисов и снижается риск ошибок при релизах, обеспечивая частые и безопасные поставки новых функций.

Важно отметить, что CD включает две схожие, но различающиеся по степени автоматизации практики:

• Continuous Deployment — непрерывное развертывание, при котором каждое изменение автоматически попадает в продакшн после прохождения всех проверок.
• Continuous Delivery — непрерывная доставка, когда код автоматически готовится к релизу, но финальное развертывание выполняется вручную, оставаясь под контролем человека.

Принципы

Эффективное внедрение CI/CD опирается на несколько фундаментальных принципов, обеспечивающих стабильность, предсказуемость и скорость доставки изменений:

• Полная автоматизация процессов. Все повторяющиеся операции — сборка, тестирование, настройка окружений, развёртывание и генерация документации — выполняются автоматически, минимизируя человеческий фактор и ускоряя цикл разработки.
• Версионирование всего. Не только исходный код, но и конфигурации, скрипты развертывания, схемы баз данных и артефакты должны храниться в системе контроля версий. Это обеспечивает прозрачность, воспроизводимость и простоту аудита изменений.
• Фокус на раннем выявлении проблем. Быстрые проверки, такие как линтеры и юнит-тесты, запускаются сразу после коммита, а более комплексные интеграционные тесты и проверки безопасности выполняются последовательно, позволяя оперативно реагировать на потенциальные сбои.
• Идентичность процессов для всех окружений. Развёртывание в тестовых, стейджинговых и продакшн-средах проходит по единым стандартам, различаясь лишь параметрами данных и масштабом, что исключает неожиданные различия и повышает стабильность системы.
• Минимизация рисков через небольшие итерации. Частые и компактные изменения легче проверять, тестировать и внедрять, что снижает вероятность крупных сбоев, упрощает откат и повышает общее качество продукта.

Следование этим принципам формирует надёжный, прозрачный и быстрый процесс поставки ПО, который приносит ощутимые выгоды как команде разработки, так и бизнесу.

Методология

CI/CD объединяет процессы интеграции, тестирования и развертывания кода в единый автоматизированный конвейер. Каждое изменение кода последовательно проходит через сборку, тестирование и подготовку к выпуску, что делает процесс выпуска управляемым и предсказуемым.

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

Простыми словами

CI/CD — это способ работы с программным обеспечением, при котором каждый новый кусок кода автоматически проверяется, тестируется и готовится к выпуску. Изменения быстро доходят до рабочей версии без ручного вмешательства.

Процесс объединяет интеграцию кода, тестирование и доставку обновлений в единый поток. Команда видит, что происходит с каждой версией, а выпуск новых функций и исправлений становится стабильным и быстрым

А теперь для чайников

Представьте, что разработка по CI/CD — это технический конвейер, только для программного кода. Каждый раз, когда программист вносит изменения, система сама проверяет их, собирает программу и готовит к работе без участия человека.

Есть тесты, которые запускаются автоматически, как инспектор качества на фабрике. Если что-то не так — сразу сигнал, если всё в порядке — код движется дальше, и разработчики сразу видят результаты.

После проверки система может сама «выпустить» новую версию для пользователей или на тестовый сервер. Новые функции и исправления появляются быстро, без ручного переноса файлов и команд, и весь процесс идёт гладко и предсказуемо.

Примеры

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

В нашем примере будет используется единая среда, где CI (Continuous Integration) проверяет корректность кода, а CD (Continuous Delivery / Deployment) отвечает за автоматическое развертывание продукта после успешной проверки.

• Репозиторий GitHub с исходным кодом проекта.
• Контроллер автоматизации (например, AWX или Ansible Tower).
• Webhook-события, которые связывают GitHub и контроллер и уведомляют о новых коммитах или Pull Request.

Общая схема работы:

Разработчик → GitHub → Контроллер → GitHub/Развертывание

• Разработчик — пишет код, создаёт или изменяет файлы в проекте, инициируя процесс проверки.
• GitHub — принимает изменения и через webhook уведомляет контроллер о новом событии.
• Контроллер — выполняет CI: клонирует репозиторий, запускает тесты, проверяет код. Если всё успешно, продолжает процесс CD: развертывание на тестовом или рабочем окружении.
• GitHub/Развертывание — получает обратную связь о статусе проверки и развертывания. В случае успеха код интегрируется в мастер-ветку, продукт обновляется.

Подготовка репозитория и файлов проекта

Создаём новый репозиторий на GitHub. В корне создаём основной скрипт project.sh, который будет проверяться CI и разворачиваться CD.

Внутри project.sh пишем простую команду вывода текста и задаём код возврата: 0 — успешное выполнение, 1 — ошибка.

Далее создаём каталог aac/ для playbook-файлов Ansible:

• ci.yml — проверка кода и запуск тестов
• cd_check.yml — проверка ветки master
• cd_deploy.yml — развертывание

Структура репозитория:

./
├── aac/
│   ├── ci.yml
│   ├── cd_check.yml
│   └── cd_deploy.yml
└── project.sh

Настройка webhook

Webhook сообщает контроллеру о событиях в GitHub, чтобы CI/CD запускался автоматически. Это механизм обратной связи: GitHub уведомляет контроллер о создании или обновлении Pull Request или Push.

• Для CI:
  • Событие: Pull Request
  • Payload URL: адрес из шаблона CI контроллера
  • Content type: application/json
  • Secret: секретный ключ CI
• Для CD:
  • Событие: Push
  • Payload URL: адрес шаблона CD
  • Content type: application/json
  • Secret: ключ CD

Если используется самоподписанный SSL-сертификат, проверку SSL можно временно отключить. После настройки webhook каждый Pull Request или Push автоматически вызывает проверку и развертывание.

Контроллер автоматизации

На этом этапе создаётся логическая структура для управления CI/CD процессами. Сначала формируется организация, например cicd, где будут объединены все проекты и их окружения. Далее добавляется Credential — персональный токен GitHub (Personal Access Token), который обеспечивает безопасное взаимодействие между системой и репозиторием.

После добавления токена создаётся проект и указывается URL репозитория GitHub — проект становится источником данных для всех процессов сборки и деплоя.

Конфигурация CI

Для автоматизации проверок создаётся шаблон CI с указанием основного playbook и включением параллельных задач:

Playbook: aac/ci.yml
Enable Webhook: true
Enable Concurrent Jobs: true

Это позволяет запускать тесты и анализ кода при каждом изменении в репозитории — без ручного вмешательства.

Конфигурация CD

Для этапа доставки продукта создаются два шаблона:

cd_check.yml   — проверка стабильности ветки master
cd_deploy.yml  — автоматическое развёртывание продукта

Затем выстраивается последовательность выполнения (workflow), чтобы обеспечить контроль и согласование перед релизом:

cd_check → Approval → cd_deploy

После сохранения настроек контроллер автоматически генерирует URL и секрет для webhook. Эти данные вставляются в настройки GitHub, чтобы система могла получать события о коммитах и запускать процессы CI/CD в реальном времени.

Работа CI

Разработчик создаёт новую ветку, изменяет project.sh и создаёт Pull Request. GitHub уведомляет контроллер через webhook. Контроллер выполняет:

• клонирование репозитория
• отображение изменённых файлов
• запуск тестов

Пример aac/ci.yml для проверки project.sh:

- hosts: localhost
  tasks:
    - name: Копирование project.sh
      copy:
        src: project.sh
        dest: /tmp/project.sh
        mode: '0755'
    - name: Запуск теста
      command: /tmp/project.sh
      register: test_result
      ignore_errors: yes
    - name: Проверка результата
      fail:
        msg: "CI тест не пройден!"
      when: test_result.rc != 0

register: test_result сохраняет код возврата.
test_result.rc == 0 — тест пройден, 1 — ошибка.

0  # тест пройден
1  # тест не пройден

Если тест не пройден, разработчик исправляет код и создаёт новый Pull Request.

Работа CD

После успешного CI ветка объединяется с master. GitHub уведомляет контроллер о Push и автоматически запускается процесс CD:

• cd_check — проверяет, что изменения в master
• Approval — ожидает ручного подтверждения
• cd_deploy — разворачивает продукт

Пример aac/cd_check.yml:

- hosts: localhost
  tasks:
    - name: Проверка ветки
      command: git rev-parse --abbrev-ref HEAD
      register: branch
    - name: Fail если не master
      fail:
        msg: "CD запускается только для master!"
      when: branch.stdout != "master"

Пример aac/cd_deploy.yml:

- hosts: production
  tasks:
    - name: Копирование приложения
      copy:
        src: /tmp/project.sh
        dest: /opt/project/project.sh
        mode: '0755'
    - name: Перезапуск сервиса
      systemd:
        name: project.service
        state: restarted

После подтверждения процесс развёртывания выполняется автоматически.

Проверка процесса

В project.sh можно временно поставить код ошибки 1, чтобы проверить, что CI фиксирует сбои. GitHub покажет «All checks have failed», контроллер отметит failed.

После исправления кода на 0 и создания нового Pull Request GitHub покажет «All checks have passed». После слияния ветки workflow CD проверит ветку, дождётся подтверждения и выполнит развёртывание.

Весь процесс CI/CD полностью автоматизирован: код проверяется, тестируется и разворачивается без ручных действий, а разработчик получает понятную обратную связь на каждом этапе.

Как работает конвейер и пайплайн CI/CD

Конвейер CI/CD и пайплайн формируют единый поток, который объединяет все этапы разработки, тестирования и доставки кода, превращая их в управляемый и автоматизированный процесс. Каждый шаг проверяет код, запускает тесты, собирает файлы и подготавливает продукт к развертыванию, обеспечивая стабильную версию для рабочей среды и мгновенную обратную связь для разработчиков. Всё это тесно связано с циклом CI/CD: изменения проходят через последовательность этапов, каждый из которых выполняет конкретную задачу.

Конвейер

Конвейер CI/CD — это последовательность автоматизированных этапов, через которые проходит программное обеспечение — от внесения изменений в код до финального развертывания на рабочей платформе. Он объединяет процессы сборки, тестирования и доставки кода, позволяя командам быстро и безопасно переносить обновления в тестовые и рабочие среды.

С развитием микросервисной архитектуры современные приложения состоят из множества независимых компонентов, которые обновляются ежедневно. Ручное развертывание и проверка таких систем стало слишком медленным и ненадежным. Конвейер CI/CD решает эту проблему, автоматически обрабатывая изменения по триггеру — например, при коммите разработчика в репозиторий запускаются проверка, сборка, тестирование и подготовка к развертыванию.

Конвейер CI/CD состоит из нескольких этапов:

1. Этап источника. Код извлекается из системы контроля версий, например Git, и фиксируется в репозитории.
2. Этап сборки. Исходный код компилируется или собирается в исполняемый артефакт.
3. Этап тестирования. Автоматические модульные и интеграционные тесты проверяют стабильность и корректность изменений.
4. Этап развертывания. Успешный код отправляется в промежуточное или производственное окружение. При необходимости применяется ручное подтверждение.

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

Пайплайн

Пайплайн CI/CD — автоматизированная последовательность действий для интеграции, тестирования и доставки обновлений программного обеспечения. Изменения кода проходят проверку, тесты и подготовку к развертыванию в чёткой, последовательной последовательности.

Пайплайн начинается с непрерывной интеграции (CI). На этом этапе разработчики регулярно отправляют изменения в центральный репозиторий, где код автоматически проверяется и компилируется.

После успешной интеграции запускается процесс автоматического тестирования. В него могут входить модульные, интеграционные и функциональные тесты. Если все проверки проходят успешно, пайплайн переходит к этапу непрерывной доставки или развертывания (CD).

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

CI/CD-пайплайны используют широкий набор инструментов и технологий, включая системы контроля версий (Git), средства непрерывной интеграции (Jenkins, Travis CI, GitLab CI/CD), платформы для автоматического развертывания (Docker, Kubernetes), а также решения для тестирования и управления конфигурацией. Подробнее о них мы поговорим чуть позже.

Основная задача CI/CD-пайплайна — ускорить и автоматизировать процесс разработки и доставки программного обеспечения, обеспечивая быструю поставку новых возможностей при минимальном риске.

Ключевые функции пайплайна включают:

• Регулярное внесение изменений в центральный репозиторий. Это позволяет оперативно выявлять конфликты и ошибки, повышая качество кода.
• Автоматический запуск различных тестов: модульных, интеграционных и функциональных, что обеспечивает раннее выявление проблем.
• Сборка и упаковка программного обеспечения в пакеты или контейнеры, подготовка релизов к развертыванию.
• Автоматическая доставка или развертывание приложения в тестовые, стейджинговые и рабочие среды после успешного тестирования. Часто используется GitLab CI/CD с GitLab Runner для организации этих процессов.
• Сбор метрик и журналов, формирование отчетов о результатах тестов, что помогает отслеживать стабильность и производительность приложения.

Цикл

Цикл CI/CD — это повторяющийся процесс, через который проходят изменения в коде от разработки до развертывания. Он объединяет автоматизированные действия, обеспечивая стабильность, прозрачность и скорость поставки продукта.

Стандарнтный цикл состоит из нескольких взаимосвязанных этапов, которые выполняются последовательно или параллельно, в зависимости от настройки пайплайна:

• Извлечение и интеграция кода (Source/Integration) — изменения кода загружаются в систему контроля версий (например, Git). Сразу запускается проверка синтаксиса и сборка проекта для обнаружения конфликтов и ошибок на ранних стадиях.
• Компиляция и сборка (Build) — исходный код компилируется или собирается в пакеты, создаются контейнеры или артефакты, необходимые для тестирования и развертывания.
• Автоматическое тестирование (Test) — выполняются модульные, интеграционные и функциональные тесты, иногда подключаются статический анализ кода, проверки безопасности и соответствия стандартам.
• Проверка качества и контроль (Validation/QA) — анализируются результаты тестирования и проверяются соответствия требований. Иногда добавляются контрольные точки для утверждения релиза ответственными лицами.
• Развертывание (Deploy/Delivery) — приложение автоматически разворачивается в промежуточной или тестовой среде. При успешном прохождении тестов происходит доставка в рабочую среду.
• Мониторинг и сбор обратной связи (Monitoring/Feedback) — собираются метрики производительности, логи и отчёты о тестирования. Команды разработки и эксплуатации получают информацию о стабильности приложения, выявленных ошибках и состоянии инфраструктуры.
• Циклическое повторение (Iteration) — каждая новая итерация кода проходит те же этапы, что обеспечивает непрерывное обновление и постепенное улучшение продукта.

Этапы

Этапы CI/CD — это не просто последовательность действий, а тщательно продуманные шаги, каждый из которых решает конкретную задачу и обеспечивает надёжность всего процесса. Помимо базовых шагов (сборка, тестирование, развертывание), современные конвейеры включают дополнительные проверки и подготовительные действия:

• Анализ кода (Code Analysis) — проверка стиля, безопасности и качества кода. Используются линтеры, статический анализ, проверки уязвимостей. Это помогает поддерживать стандарты и предотвращает появление ошибок ещё до тестирования.
• Подготовка окружения (Environment Setup) — на этом этапе создаются контейнеры, виртуальные машины или среды для тестирования и развертывания, чтобы код всегда запускался в одинаковых условиях.
• Сборка артефактов (Artifact Build) — исходный код превращается в готовые к использованию пакеты, библиотеки, контейнерные образы. Это обеспечивает переносимость и воспроизводимость релизов.
• Автоматическое тестирование (Automated Testing) — кроме стандартных модульных и интеграционных тестов, могут выполняться нагрузочные тесты, проверка совместимости, UI-тесты и тестирование API.
• Развертывание (Deployment/Delivery) — автоматическое или полуавтоматическое переносение приложения в тестовые, стейджинговые или рабочие среды. На некоторых этапах могут быть контрольные точки для ручного согласования перед продакшном.
• Мониторинг и обратная связь (Monitoring & Feedback) — сбор логов, метрик, результатов тестов, уведомления о сбоях. Это позволяет команде быстро реагировать на проблемы и улучшать процесс.

Как применяется

CI/CD нашёл широкое применение и используется не только для автоматизации сборки и развертывания, но и для упрощения тестирования и поддержки DevOps-практик. Он позволяет командам работать более слаженно, ускоряет интеграцию изменений и делает процессы доставки кода прозрачными.

CI/CD в программировании

CI/CD в программировании превращает рутинные задачи в автоматизированные процессы. Каждый коммит автоматически проверяется на соответствие стандартам, проходит тестирование и при успешной проверке интегрируется в основную ветку проекта. Разработчики сосредотачиваются на логике приложения, а не на ручной проверке и сборке.

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

CI/CD поддерживает единый стиль и стандарты кодирования. Скрипты проверяют соответствие код-стайлу, анализируют потенциальные уязвимости и формируют рекомендации. Качество кода остаётся высоким, баги выявляются ещё до этапа тестирования.

CI/CD в DevOps

CI/CD в рамках DevOps превращается в связующее звено между разработкой и эксплуатацией. Практики автоматизации интеграции и доставки кода становятся частью повседневной работы, и процессы разрабатываются так, чтобы минимизировать ручные вмешательства. Взаимодействие команд становится прозрачным, а каждый шаг в цепочке от коммита до развертывания под контролем.

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

В работе DevOps CI/CD внедряется почти во все процессы, где возможна автоматизация и контроль изменений.

Инструменты CI/CD становятся центром управления жизненным циклом приложений. Они фиксируют все изменения, создают отчёты о тестах и интеграциях, и обеспечивают единую точку контроля. Команды получают чёткое понимание статуса проекта в любой момент, что делает DevOps-подход структурированным и управляемым.

CI/CD в тестировании

В цепочке CI/CD тестирование становится встроенным этапом, а не отдельной операцией. После каждого коммита автоматически запускаются модульные и интеграционные тесты, фиксируя ошибки на ранней стадии.

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

Результаты интегрируются прямо в цепочку CI/CD. Неудачные тесты останавливают прогон сборки, а успешные — автоматически переходят к следующему этапу, будь то упаковка, создание артефактов или подготовка к развертыванию. Каждая итерация превращается в живой поток проверки качества.

Инструменты и настройка

Ранее мы уже упоминали инструменты и настройку CI/CD, но теперь пришло время рассмотреть их более подробно. От того, насколько грамотно они внедрены, зависит скорость разработки, стабильность релизов и удобство сопровождения проекта. Важно не только знать их возможности, но и понимать, как применять их на практике — именно это формирует основу для эффективной работы в DevOps-среде.

GitHub

GitHub — это основная платформа, на которой строятся практически все современные процессы CI/CD. Здесь хранятся исходники проектов, фиксируются изменения, создаются ветки и Pull Request, а также отслеживается вся история разработки. Репозиторий становится центром взаимодействия команды — все изменения видны, проверяются и проходят согласование перед объединением.

Actions

Главное преимущество GitHub в том, что автоматизация встроена прямо в платформу. Для этого используется система GitHub Actions — инструмент, который запускает сценарии при любом событии в репозитории. Коммит, открытие Pull Request или публикация релиза могут автоматически инициировать тесты, сборку и деплой приложения.

Каждый workflow описывается в YAML-файлах, расположенных в каталоге .github/workflows/. Структура проста: workflow — набор задач (jobs), каждая из которых состоит из шагов (steps). Шаг может использовать готовые actions — небольшие команды для выполнения конкретных действий. Например, actions/checkout загружает код из репозитория, а actions/setup-python готовит окружение для тестов.

sudo apt update
sudo apt install -y docker.io docker-compose

sudo systemctl enable --now docker

sudo groupadd docker || true
sudo usermod -aG docker $USER

sudo adduser frontend
sudo usermod -aG docker frontend
sudo usermod -aG sudo frontend

ssh-keygen -t ed25519 -C "github-actions-deploy" -f gh_deploy_key
# приватный gh_deploy_key добавите в Secrets на GitHub, публичный — в ~/.ssh/authorized_keys на сервере

sudo systemctl stop nginx

# syntax=docker/dockerfile:1

# Сборка приложения
FROM node:16-alpine AS build
RUN apk add --no-cache python2 g++ make
WORKDIR /app
COPY package*.json ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

# Контейнер для сервинга через Nginx
FROM nginx:1.19-alpine
COPY ./nginx/nginx.conf /etc/nginx/nginx.conf
COPY --from=build /app/build /usr/share/nginx/html

http {
  server {
    listen 80;
    server_name your.domain.example;

    root   /usr/share/nginx/html;
    index  index.html index.htm;

    location / {
      try_files $uri $uri/ /index.html;
    }
  }
}

#!/bin/bash
set -e

REPO="${1:-yourdockeruser/yourrepo}"
CONTAINER_NAME="frontend"
IMAGE="$REPO:latest"

echo "--- Stopping container if exists ---"
if docker ps -q --filter "name=${CONTAINER_NAME}"; then
  docker stop ${CONTAINER_NAME} || true
  docker rm ${CONTAINER_NAME} || true
fi

echo "--- Removing old image ---"
docker image prune -af || true

echo "--- Pull new image ---"
docker pull ${IMAGE}

echo "--- Run new container ---"
docker run -d --restart unless-stopped -p 80:80 --name ${CONTAINER_NAME} ${IMAGE}

echo "Deploy finished"

name: Publish and deploy

on:
  push:
    branches: [ "master" ]

jobs:
  push_to_registry:
    name: Build and push Docker image
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Extract metadata (tags)
        id: meta
        uses: docker/metadata-action@v4
        with:
          images: ${{ secrets.DOCKER_REPO }}
          tags: type=raw,value=latest

      - name: Build and push
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}

  server_update:
    name: Deploy to server via SSH
    runs-on: ubuntu-latest
    needs: push_to_registry
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup SSH key
        uses: webfactory/ssh-agent@v0.8.1
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Run deploy script on server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          port: ${{ secrets.SERVER_PORT }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /home/${{ secrets.DEPLOY_USER }} || exit 1
            ./deploy.sh ${{ secrets.DOCKER_REPO }}

name: Docker Image CI

on:
  pull_request:
    branches: [ "master" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build the Docker image
        run: |
          docker build . -t pr-check:$(date +%s)

Django

Django — это популярный Python-фреймворк для создания веб-приложений любой сложности. Он включает маршрутизацию, ORM для работы с базой данных, систему шаблонов и встроенные механизмы безопасности.

GitHub Actions позволяет интегрировать Django-проекты в CI/CD-процесс: проверять код, запускать миграции, устанавливать зависимости и готовить приложение к развертыванию. Каждая workflow состоит из job’ов и шагов, что делает процесс гибким и прозрачным.

Часто Django используют вместе с Amazon Web Services (Amazon EC2 и CodeDeploy), чтобы автоматически деплоить приложение на сервер без контейнеризации.

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

Этап 1. Настройка манифеста деплоя (appspec.yml)

В корне проекта создаем файл appspec.yml, который сообщает AWS CodeDeploy, какие файлы копировать и какие скрипты запускать до и после установки. В разделе files указываем источник и директорию назначения, а в hooks прописываем подготовительные скрипты:

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/django-aws_cicd
hooks:
  BeforeInstall:
      - location: scripts/before_install.sh
  AfterInstall:
      - location: scripts/after_install.sh

Этот файл является основой деплоя, он сообщает системе CodeDeploy, что запускать сначала before_install.sh, а после установки — after_install.sh.

Этап 2. Подготовка сервера (before_install.sh)

Скрипт before_install.sh подготавливает сервер для установки приложения. Сначала очищаем старые установки, затем устанавливаем агент CodeDeploy, обновляем систему и устанавливаем Python и инструменты для виртуального окружения. После этого удаляем старую версию приложения для чистого деплоя:

#!/usr/bin/env bash

sudo rm -rf /home/ubuntu/install

sudo apt-get -y update
sudo apt-get -y install ruby wget
cd /home/ubuntu
wget https://aws-codedeploy-us-east-1.s3.amazonaws.com/latest/install
sudo chmod +x ./install
sudo ./install auto

sudo apt-get update
sudo apt-get install -y python3 python3-dev python3-pip python3-venv
pip install --user --upgrade virtualenv

sudo rm -rf /home/ubuntu/django-aws_cicd

Этот этап гарантирует, что сервер готов к установке, агент CodeDeploy работает, а система имеет все необходимые инструменты для Python и виртуальных окружений.

Этап 3. Настройка и запуск приложения (after_install.sh)

После установки файлов на сервер скрипт after_install.sh останавливает все предыдущие серверы Django, активирует виртуальное окружение, устанавливает зависимости и запускает сервер в фоновом режиме:

#!/usr/bin/env bash

sudo pkill -f runserver

cd /home/ubuntu/django-aws_cicd/

python3 -m venv venv
source venv/bin/activate

pip install -r requirements.txt

screen -d -m python3 manage.py runserver 0:8000

Таким образом приложение разворачивается в чистом окружении, зависимости устанавливаются автоматически, и сервер Django запускается без блокировки терминала. Этот скрипт можно адаптировать для использования Gunicorn или Nginx в продакшен-режиме.

Этап 4. Настройка AWS и CI/CD

Для полноценного автоматического деплоя необходимо настроить AWS:

• Создать IAM роли: AmazonEC2RoleforAWSCodeDeploy для EC2 и AWSCodeDeployRole для CodeDeploy.
• Запустить EC2 с ролью AmazonEC2RoleforAWSCodeDeploy и добавить user data для установки агента CodeDeploy:

#!/usr/bin/env bash
sudo apt-get -y update
sudo apt-get -y install ruby wget
cd /home/ubuntu
wget https://aws-codedeploy-us-east-1.s3.amazonaws.com/latest/install
sudo chmod +x ./install
sudo ./install auto

• Настроить Security Group для разрешения порта 8000 (или другого порта вашего Django-приложения).
• Создать приложение и Deployment Group в CodeDeploy, привязав EC2 instance и роль AWSCodeDeployRole.
• Настроить CodePipeline: подключение к GitHub, выбор репозитория и ветки, выбор CodeDeploy как этапа деплоя.

После этого GitHub Actions и AWS автоматически собирают код, проверяют зависимости, запускают миграции и деплоят приложение на сервер.

Результат

Откройте Public IPv4 DNS вашего EC2 и перейдите по адресу:

http://<Public IPv4 DNS>:8000

Готово. Вы увидите работающий Django-проект, который обновляется автоматически при каждом пуше в репозиторий.

Docker

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

Docker — это open-source платформа для развертывания, масштабирования и управления приложениями. Она использует контейнеры, которые включают код, библиотеки, runtime и системные утилиты. Контейнеры лёгкие, потому что используют одно ядро операционной системы, при этом остаются изолированными друг от друга.

С Docker проще работать с тестами и сборкой: можно быстро поднять среду, прогнать автоматические тесты и убедиться, что код одинаково работает везде. Контейнеры легко создавать и удалять, что делает CI/CD пайплайны гибкими и ускоряет выпуск новых версий приложения.

Как Docker поддерживает процессы CI/CD

Контейнеризация обеспечивает единообразие среды на всех этапах разработки и продакшена, что решает проблему «у меня работает, а на сервере нет». Docker позволяет быстро запускать тесты в изолированных контейнерах, не влияя на другие проекты, и обеспечивает повторяемость сборки. Благодаря этому цикл интеграции и деплоя становится быстрее, а качество кода выше.

Docker легко интегрируется с CI/CD инструментами, такими как GitHub Actions, Jenkins или CircleCI. Это позволяет автоматически собирать Docker-образы, тестировать их и пушить в Docker Hub или приватные реестры. Автоматизация сокращает ручную работу и делает процесс сборки и деплоя предсказуемым и надежным.

Пример настройки CI/CD с Docker

Для примера возьмем Java-приложение, но принципы универсальны для любых проектов, включая Django. Сначала необходимо подготовить репозиторий и Docker-файлы:

git clone https://github.com/your-username/sample-app.git
cd sample-app

Создайте необходимые файлы:

• Dockerfile — инструкции для сборки контейнера.
• .dockerignore — файлы и папки, которые не нужно включать в образ.
• docker-compose.yaml — описание сервисов и сетей.

Запуск приложения локально:

docker-compose up --build

Фоновый запуск:

docker-compose up --build -d

Остановка контейнеров:

docker-compose down

Далее настраиваем CI/CD с помощью GitHub Actions. Создайте в репозитории папку .github/workflows и файл main.yml:

name: CI/CD Docker

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Docker Hub Login 
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build and Test Docker image
        uses: docker/build-push-action@v6
        with:
          target: test
          load: true

      - name: Build and Push final image
        uses: docker/build-push-action@v6
        with:
          platforms: linux/amd64,linux/arm64
          push: true
          target: final
          tags: ${{ secrets.DOCKER_USERNAME }}/sample-app:latest

В настройках репозитория GitHub добавьте секреты:

• DOCKER_USERNAME — ваш Docker Hub ID
• DOCKER_PASSWORD — токен доступа к Docker Hub

После пуша в main ветку GitHub Actions автоматически клонирует репозиторий, настроит Docker Buildx, соберет и протестирует образ в контейнере, а затем соберет финальный образ и отправит его в Docker Hub, обеспечивая быстрый и предсказуемый процесс деплоя.

Советы для эффективного CI/CD с Docker

• Используйте многоступенчатую сборку, отделяя этап сборки приложения от этапа запуска, чтобы итоговый образ был компактным и легким
• Оптимизируйте кэш Docker, располагая редко меняющиеся слои в начале Dockerfile, а часто меняющиеся — в конце, что ускоряет повторные сборки
• Запускайте тесты параллельно в нескольких контейнерах, чтобы ускорить обратную связь и сразу выявлять проблемы в коде
• Повторно используйте слои между сборками на CI/CD раннерах, это экономит время и ресурсы при частых деплоях
• Регулярно сканируйте образы на уязвимости с помощью инструментов Trivy или Clair перед пушем в реестр

Следуя этим шагам, можно построить стабильный и повторяемый процесс CI/CD с Docker, автоматизировать тестирование и деплой, а также обеспечить одинаковое окружение на всех этапах разработки.

GitLab

GitLab — это инструмент для хранения и управления репозиториями Git. Он позволяет нескольким командам одновременно работать над проектом, вносить изменения, применять обновления и при необходимости откатывать их. GitLab поддерживает гибкую работу с ветками и запросами на слияние, что упрощает контроль версий и совместную разработку.

GitLab делит функционал на категории, охватывающие все аспекты разработки и эксплуатации:

• Управление (Manage) — аутентификация и авторизация с поддержкой SSO и токенов, аналитика продуктивности команд.
• Планирование (Plan) — отслеживание задач и проблем, контроль времени на выполнение задач, возможность прикреплять файлы и вести обсуждения.
• Создание (Create) — управление исходным кодом, графики коммитов, ветки, слияния и интеграция с Jira, веб-редактор кода.
• Проверка (Verify) — поддержка CI, тестирование, проверка качества кода, нагрузочное тестирование и тесты на доступность.
• Упаковка (Package) — управление репозиториями разных языков, работа с контейнерами и Docker-образами.
• Безопасность (Secure) — SAST и DAST, сканирование зависимостей, отчеты по уязвимостям.
• Релизы (Release) — поддержка Continuous Delivery, канареечные релизы, управление окружениями и доступом.
• Конфигурирование (Configure) — управление кластерами Kubernetes, переменные окружений, ChatOps и бессерверные функции.
• Мониторинг (Monitoring) — сбор метрик, логирование, автоматические инциденты, интеграция с внешними системами.
• Защита (Defend) — Web Application Firewall, защита контейнеров, микросегментация и политики безопасности.

Чем отличается от GitHub

GitLab и GitHub — популярные платформы для работы с Git-репозиториями, но между ними есть несколько ключевых отличий. GitHub появился на три года раньше GitLab и стал стандартом хранения репозиториев с открытым исходным кодом. GitHub полностью облачное решение, тогда как GitLab может работать как в облаке, так и на локальном сервере. На официальном сайте GitLab даже есть отдельная страница с подробным сравнением возможностей этих платформ.

GitLab представляет собой полноценную DevOps-платформу, а не просто хостинг для Git-репозиториев. В нем встроены инструменты CI/CD, управление задачами, мониторинг и безопасность, что позволяет вести проект полностью внутри одной системы. GitHub же полностью сосредоточен на хранении кода и его доступе через интеграции с внешними инструментами.

Как установить GitLab (Ubuntu)

Платформа может быть развернута на выделенном сервере или в облаке. Для обоих случаев доступны бесплатная версия GitLab CE и платные тарифы, которые расширяют возможности управления пользователями, безопасности и CI/CD. Например, на выделенном сервере можно использовать стандартную конфигурацию: процессор Intel Xeon E-2236, 16 ГБ ОЗУ, два SSD-диска по 480 ГБ и Ubuntu 20.04 LTS 64-bit.

После подготовки сервера подключаемся к нему по SSH, переходим в каталог /tmp и загружаем установочный скрипт GitLab:

cd /tmp
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
chmod +x script.deb.sh
bash /tmp/script.deb.sh

Далее устанавливаем GitLab через менеджер пакетов apt:

apt install gitlab-ce

После установки открываем файл конфигурации /etc/gitlab/gitlab.rb и указываем URL сервера:

external_url "http://<IP-адрес или домен>"

Применяем изменения командой:

gitlab-ctl reconfigure

Теперь можно зайти в веб-интерфейс GitLab и задать пароль администратора.

По умолчанию GitLab работает по HTTP. Чтобы включить HTTPS, нужно включить Let’s Encrypt и указать email для сертификата:

letsencrypt['enable'] = true
external_url "https://<IP-адрес или домен>"
letsencrypt['contact_emails'] = ['test@example.com']

После этого выполняем повторную реконфигурацию:

gitlab-ctl reconfigure

Если GitLab доступен только во внутренней сети, можно настроить проксирование через Nginx с Let’s Encrypt.

В случае ошибок 502 при доступе через веб-интерфейс чаще всего виноваты: недостаток памяти, остановка службы gitlab-workhorse или проблемы с правами на сокет /var/opt/gitlab/gitlab-workhorse/socket. Решается добавлением памяти, перезапуском сервисов или исправлением прав доступа.

Настройка

Перед началом работы с GitLab важно правильно настроить подключение и доступ к репозиториям. Это обеспечит безопасный обмен данными и упростит взаимодействие с кодом через командную строку. Рассмотрим процесс настройки пошагово.

Шаг 1. Генерация SSH-ключей

Чтобы каждый раз не вводить логин и пароль при работе с GitLab, используется аутентификация по SSH-ключам. Для этого создаётся пара ключей — приватный и публичный. Приватный хранится на локальной машине, а публичный добавляется в GitLab.

ssh-keygen -t rsa -b 4096 -f ~/.ssh/gitlab

После выполнения команды система спросит путь для сохранения ключа и парольную фразу. Пароль можно оставить пустым, но для большей безопасности рекомендуется указать фразу-пароль (passphrase).

Затем выведите содержимое публичного ключа, чтобы добавить его в GitLab:

cat ~/.ssh/gitlab.pub

Скопируйте весь текст от ssh-rsa до конца строки.

Шаг 2. Добавление SSH-ключа в GitLab

В веб-интерфейсе GitLab перейдите в User Settings → SSH Keys. Вставьте скопированный ключ в поле Key, при желании укажите название и срок действия, затем нажмите Add key.

Теперь ваш компьютер авторизован, и можно выполнять операции с репозиториями без ввода логина и пароля. Проверить соединение можно командой:

ssh -T git@gitlab.com

Если всё настроено правильно, вы увидите сообщение вроде «Welcome to GitLab, username!».

Шаг 3. Создание нового проекта

После настройки доступа можно создать новый проект. Для этого на главной странице GitLab нажмите + → New project. Далее выберите:

• Private — доступ только у вас;
• Internal — доступ у всех пользователей вашего GitLab-сервера;
• Public — проект открыт для всех, включая гостей.

Укажите название, при необходимости описание и параметры видимости, затем нажмите Create project.

Шаг 4. Добавление участников и прав доступа

После создания проекта перейдите во вкладку Members. Здесь можно пригласить других пользователей и назначить им роли:

• Guest — просмотр и комментарии;
• Reporter — доступ к просмотру кода и отчетам;
• Developer — возможность коммитить и создавать ветки;
• Maintainer — полный контроль над проектом;
• Owner — только для создателя или администратора.

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

Шаг 5. Загрузка локального репозитория

Если у вас уже есть локальный репозиторий, его можно связать с новым проектом в GitLab. Для этого в терминале выполните:

git remote add origin git@<IP-адрес>:username/project-name.git
git push -u origin master

После отправки кода проект появится в веб-интерфейсе. Теперь вы можете просматривать файлы, коммиты, ветки и историю изменений прямо из браузера.

Чтобы клонировать проект обратно на другую машину, используйте:

git clone git@<IP-адрес>:username/project-name.git

Также можно скачать проект архивом — через кнопку Download → ZIP в интерфейсе GitLab.

Шаг 6. Работа с ветками

По умолчанию основная ветка называется master или main. Чтобы изолировать новую функциональность, создавайте отдельные ветки. Это помогает тестировать изменения, не затрагивая стабильную версию кода.

Создадим новую ветку:

git checkout -b development

После внесения изменений добавляем файлы, коммитим и отправляем в GitLab:

git add .
git commit -m "new feature"
git push --set-upstream origin development

Теперь ветка появится в GitLab в разделе Repository → Branches. В настройках проекта (Settings → Repository) можно выбрать ветку, которая будет использоваться по умолчанию.

Шаг 7. Слияние веток и Merge Requests

Когда работа в отдельной ветке завершена, её нужно объединить с основной. В GitLab для этого используется механизм Merge Request (запрос на слияние). Он позволяет обсуждать изменения, проходить ревью и контролировать процесс объединения кода.

Создаём новую ветку и добавляем изменения:

git checkout -b staging
echo "Test file" > new-staging.txt
git add new-staging.txt
git commit -m "add test file"
git push --set-upstream origin staging

После загрузки откройте GitLab, перейдите в ветку staging и нажмите Create merge request. Укажите описание, выберите базовую ветку (например, master), при необходимости отметьте ревьюеров и нажмите Submit merge request.

Когда изменения проверены, нажмите Approve и затем Merge. GitLab автоматически объединит ветки и закроет запрос. После этого можно удалить временную ветку, чтобы не засорять репозиторий.

Такие настройки помогут сделать процесс разработки безопасным и управляемым, особенно при работе в команде.

Шаг 8. Проверка подключения и работы

Чтобы убедиться, что всё работает корректно, выполните несколько команд:

git fetch origin
git pull
git push

Если Git не запрашивает пароль и успешно синхронизируется с GitLab — значит, SSH-соединение и настройки проекта работают правильно.

На этом базовая настройка завершена. Теперь вы можете полноценно работать с проектами в GitLab: создавать ветки, вносить изменения, выполнять ревью и использовать CI/CD для автоматизации сборок.

Полезные настройки проекта

• Protected branches — защита веток от случайных пушей (актуально для master/main).
• Push rules — ограничения на коммиты (например, обязательные комментарии к изменениям).
• CI/CD → Variables — добавление переменных окружения для сборок и деплоя.
• Integrations — подключение внешних сервисов (Slack, Jira, Kubernetes и др.).

Переменные (variables)

После подключения репозитория и настройки доступа самое время перейти к автоматизации. Основой для этого в GitLab служат переменные окружения — CI/CD Variables.

Например, при деплое на сервер можно сохранить логин и пароль в переменных DEPLOY_USER и DEPLOY_PASS. GitLab автоматически подставит эти значения в скрипт во время сборки, не раскрывая их в логах.

Где задаются переменные

Перейдите в меню проекта Settings → CI/CD → Variables. Здесь можно добавить переменные в разных уровнях:

• Project — переменные действуют только внутри конкретного проекта;
• Group — доступны всем проектам в группе;
• Instance — глобальные переменные для всей инсталляции GitLab (только для администраторов).

Для создания переменной нажмите Add variable, укажите ключ (например, API_TOKEN), значение (токен, пароль, ключ), и при необходимости установите флаги:

• Protected — переменная доступна только в защищённых ветках (обычно master/main);
• Masked — значение скрывается в логах, даже если кто-то попытается вывести его через echo;
• Environment scope — можно указать, для какой среды (например, staging, production) применяется переменная.

Пример использования переменных в .gitlab-ci.yml

Чтобы переменные заработали, их нужно использовать в файле .gitlab-ci.yml, который хранится в корне репозитория. Пример простого пайплайна с переменными:

stages:
  - build
  - deploy

build_job:
  stage: build
  script:
    - echo "Сборка приложения..."
    - npm install
    - npm run build

deploy_job:
  stage: deploy
  script:
    - echo "Деплой в среду $DEPLOY_ENV"
    - ssh $DEPLOY_USER@$DEPLOY_SERVER "cd /var/www && git pull"
  only:
    - main

Здесь $DEPLOY_USER, $DEPLOY_SERVER и $DEPLOY_ENV — это переменные, заданные в настройках проекта. GitLab автоматически подставит их при выполнении пайплайна.

Групповые и глобальные переменные

Если у вас несколько проектов, которые используют одинаковые настройки (например, один сервер деплоя или общий токен API), не нужно копировать значения вручную. GitLab позволяет задать переменные на уровне группы.

Для этого откройте Group → Settings → CI/CD → Variables и добавьте их там. Все проекты в этой группе смогут использовать их без дополнительных настроек.

Переменные окружения для разных сред

GitLab CI/CD поддерживает развёртывание в разные окружения — staging, testing, production и т.д. Чтобы автоматизировать это, можно задать разные наборы переменных для каждой среды. Например:

• DEPLOY_SERVER = staging.example.com (для тестовой среды)
• DEPLOY_SERVER = prod.example.com (для продакшена)

В настройках переменной укажите Environment scope и впишите имя окружения — например, production или staging. Тогда GitLab сам выберет правильные значения при запуске пайплайна.

Безопасность переменных

При работе с секретами важно помнить о безопасности. GitLab хранит переменные в зашифрованном виде, но доступ к ним можно получить, если у пользователя есть права на изменение CI/CD настроек. Поэтому рекомендуется:

• использовать флаг Masked для всех чувствительных данных;
• не хранить токены и пароли в .gitlab-ci.yml — только в настройках интерфейса;
• задавать переменные как Protected, если они используются при продакшн-деплое;
• ограничивать доступ к проекту только проверенным пользователям.

Системные переменные

Помимо пользовательских, GitLab автоматически создаёт набор предустановленных переменных, которые можно использовать в пайплайнах. Например:

• CI_COMMIT_BRANCH — имя текущей ветки;
• CI_PROJECT_NAME — название проекта;
• CI_PIPELINE_ID — уникальный ID пайплайна;
• CI_JOB_STAGE — стадия, на которой выполняется job;
• CI_ENVIRONMENT_NAME — имя среды, если используется deploy.

Их удобно применять для автоматизации логов, динамических путей, сборок и уведомлений.

Проверка переменных

Чтобы убедиться, что переменные передаются корректно, можно добавить тестовую job в .gitlab-ci.yml:

check_vars:
  stage: test
  script:
    - echo "DEPLOY_ENV = $DEPLOY_ENV"
    - echo "SERVER = $DEPLOY_SERVER"

Значения будут подставлены при выполнении пайплайна. Если переменная не определена, в логах появится пустая строка — это поможет выявить ошибки в настройке.

Рекомендации по работе с переменными

• Используйте префиксы (PROD_, DEV_, STAGING_), чтобы не путаться в окружениях.
• Для конфигураций используйте переменные типа JSON — GitLab корректно обрабатывает такие значения.
• Регулярно проверяйте актуальность ключей и токенов (особенно API и SSH).
• Если работаете в команде — храните общие переменные на уровне группы, а не проекта.

Переменные — это фундамент CI/CD в GitLab. С их помощью можно безопасно хранить пароли, токены и настройки, разделять окружения и автоматизировать деплой. Грамотная работа с переменными делает пайплайны гибкими, безопасными и удобными в сопровождении.

Docker

Мы часто встречались с Docker в наших примерах, и теперь разберем, как использовать его для запуска GitLab. Docker позволяет быстро развернуть GitLab в контейнере, управлять его конфигурацией и переносить настройки между серверами без ручной установки.

Для начала убедитесь, что Docker установлен и работает. Контейнер GitLab использует официальные пакеты Linux, а настройки хранятся в файле /etc/gitlab/gitlab.rb. Чтобы открыть его для редактирования, сначала войдите в контейнер:

sudo docker exec -it gitlab /bin/bash

После входа можно редактировать файл напрямую в редакторе:

sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rb

В файле gitlab.rb необходимо указать external_url — адрес, по которому GitLab будет доступен. Также здесь можно настроить SMTP для отправки почты и включить HTTPS, если требуется.

После внесения изменений нужно сохранить файл и перезапустить контейнер, чтобы настройки применились:

sudo docker restart gitlab

GitLab поддерживает предварительную настройку через переменную окружения GITLAB_OMNIBUS_CONFIG. Она позволяет задавать параметры конфигурации без изменения gitlab.rb, например URL, включение LFS, или настройки базы данных. Каждое значение разделяется точкой с запятой.

sudo docker run --detach \
  --hostname gitlab.example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com'; gitlab_rails['lfs_enabled'] = true;" \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:-ee.0

Если GitLab должен быть доступен по конкретному IP, можно указать его при публикации портов:

sudo docker run --detach \
  --hostname gitlab.example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com'" \
  --publish 198.51.100.1:443:443 \
  --publish 198.51.100.1:80:80 \
  --publish 198.51.100.1:22:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:-ee.0

Для изменения стандартных портов можно использовать дополнительные публикации. Например, веб-интерфейс на 8929 и SSH на 2424:

sudo docker run --detach \
  --hostname gitlab.example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.example.com:8929'; gitlab_rails['gitlab_shell_ssh_port'] = 2424" \
  --publish 8929:8929 --publish 2424:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:-ee.0

После запуска контейнера можно войти внутрь, проверить или изменить external_url и порт SSH:

sudo docker exec -it gitlab /bin/bash
# редактируем файл
nano /etc/gitlab/gitlab.rb

# для HTTP
external_url "http://gitlab.example.com:8929"
# для HTTPS
external_url "https://gitlab.example.com:8929"

# установка SSH порта
gitlab_rails['gitlab_shell_ssh_port'] = 2424

# применяем изменения
gitlab-ctl reconfigure

Начиная с GitLab 16.0, по умолчанию используется два соединения к базе данных. Чтобы вернуть одно соединение, достаточно в gitlab.rb отключить вторую базу и перезапустить контейнер:

gitlab_rails['databases']['ci']['enable'] = false
sudo docker restart gitlab

GitLab в контейнере легко конфигурируется, порты можно менять по необходимости, включать нужные функции и управлять настройками, не затрагивая хостовую систему, что делает работу с CI/CD и тестовыми окружениями простой и предсказуемой.

Kubernetes

Kubernetes (K8n) — это платформа для управления контейнеризированными приложениями, которая позволяет автоматизировать их развёртывание, масштабирование и обслуживание. С её помощью можно управлять сотнями контейнеров одновременно, отслеживать их состояние, балансировать нагрузку и восстанавливать сервисы в случае сбоев. Платформа предоставляет единый API для работы с инфраструктурой, что упрощает процессы CI/CD и повышает надёжность хранения приложений.

Kubernetes и ранее упомянутый Docker работают с контейнерами, но выполняют разные функции. Docker отвечает за создание и запуск отдельных контейнеров, тогда как Kubernetes управляет целыми кластерами, следит за их состоянием, распределяет нагрузку и обеспечивает масштабирование.

GitLab CI/CD позволяет подключаться к кластерам Kubernetes, безопасно развертывать приложения и обновлять их. Для этого в кластере устанавливается агент, который создаёт Kubernetes-контекст и позволяет запускать команды Kubernetes API прямо из пайплайна.

Для безопасности каждый агент имеет отдельный контекст (kubecontext), и только проект, в котором настроен агент, или дополнительные авторизованные проекты могут его использовать. GitLab-раннеры, которые взаимодействуют с кластером, не обязательно должны находиться внутри него.

Авторизация и доступ к агенту

Если у вас несколько проектов с манифестами Kubernetes, необходимо авторизовать их для доступа к агенту. Это можно сделать для отдельных проектов, групп или подгрупп. Настройка авторизации занимает одну-две минуты.

Для отдельных проектов добавляется путь к проекту в config.yaml:

ci_access:
  projects:
    - id: path/to/project

Для групп и подгрупп добавляется путь к группе:

ci_access:
  groups:
    - id: path/to/group/subgroup

Также можно разрешить доступ агенту ко всем проектам GitLab-инстанса:

ci_access:
  instance: {}

После настройки все CI/CD задачи получают файл kubeconfig с контекстами для каждого агента, доступный через переменную $KUBECONFIG.

Настройка пайплайна для Kubernetes

Чтобы выполнять команды Kubernetes из pipeline, необходимо в .gitlab-ci.yml указать контекст агента и установить kubectl. Пример конфигурации:

deploy:
  image: debian:13-slim
  variables:
    KUBECTL_VERSION: v1.34
    DEBIAN_FRONTEND: noninteractive
  script:
    - apt-get update
    - apt-get install -y --no-install-recommends apt-transport-https ca-certificates curl gnupg
    - curl --fail --silent --show-error --location "https://pkgs.k8s.io/core:/stable:/${KUBECTL_VERSION}/deb/Release.key" | gpg --dearmor --output /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    - chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    - echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/${KUBECTL_VERSION}/deb/ /" | tee /etc/apt/sources.list.d/kubernetes.list
    - chmod 644 /etc/apt/sources.list.d/kubernetes.list
    - apt-get update
    - apt-get install -y --no-install-recommends kubectl
    - kubectl config get-contexts
    - kubectl config use-context path/to/agent/project:agent-name
    - kubectl get pods

Для Auto DevOps нужно определить переменную KUBE_CONTEXT с контекстом нужного агента, можно использовать разные агенты для staging и production.

Безопасность и ограничения доступа

Kubernetes позволяет ограничивать доступ к агенту через impersonation и RBAC. По умолчанию CI/CD задачи наследуют права аккаунта агента, но можно задать:

• impersonation агента (по умолчанию)
• impersonation конкретной CI/CD задачи
• impersonation статического пользователя или системного аккаунта

Кроме того, доступ можно ограничить конкретными окружениями или защищёнными ветками:

ci_access:
  projects:
    - id: path/to/project-1
      protected_branches_only: true
  groups:
    - id: path/to/group-1
      protected_branches_only: true
      environments:
        - production

Такой подход позволяет гибко управлять безопасностью, распределять права и следить за тем, чтобы задачи CI/CD использовали только разрешённые ресурсы кластера.

Rules

Правила оцениваются последовательно до первого совпадения. Как только правило срабатывает, задача либо включается в конвейер, либо исключается из него. Для каждого правила можно задавать параметры выполнения, такие как when и allow_failure. Это позволяет гибко управлять процессами CI/CD и экономить ресурсы.

Примеры использования Rules

Простейший пример с использованием if, где задача выполняется только в двух случаях:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
      allow_failure: true
    - if: $CI_PIPELINE_SOURCE == "schedule"

Если pipeline запускается для merge request, выполняется первое правило: задача добавляется как ручная (manual) и может не повлиять на общий результат конвейера (allow_failure: true). Если pipeline запланирован, срабатывает второе правило, и задача выполняется по умолчанию (when: on_success).

Исключение задач с помощью Rules

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

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - when: on_success

Задача пропускается для merge request и плановых pipeline, но выполняется во всех остальных случаях.

Запуск задач только для определённых типов пайплайна

Используя предопределённые переменные CI/CD, можно задавать, в каких типах pipeline должна выполняться задача: ветки, теги, merge request или расписание.

job1:
  script:
    - echo
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never

Задача выполняется только для merge request и плановых pipeline, но не для пушей в ветки.

Сложные условия Rules

Вы можете комбинировать несколько ключевых слов, таких как if, changes и exists в одном правиле. Задача срабатывает только если все условия одновременно верны. Например:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $VAR == "string value"
      changes:
        - Dockerfile
        - docker/scripts/**/*
      when: manual
      allow_failure: true

Задача выполняется вручную и может не повлиять на конвейер, только если изменился Dockerfile или любой файл в /docker/scripts, и переменная $VAR равна «string value».

Использование регулярных выражений и переменных

С помощью операторов =~ и !~ можно сравнивать переменные с регулярными выражениями. Это позволяет создавать гибкие правила для сложных условий. Например:

job1:
  script:
    - echo This rule uses parentheses.
  rules:
    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

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

Runner

GitLab Runner подключается к вашему экземпляру GitLab и ожидает задания CI/CD. Когда конвейер запускается, GitLab отправляет задачи доступным раннерам, которые выполняют их и возвращают результаты обратно. Среди ключевых возможностей:

• Выполнение нескольких задач одновременно;
• Использование нескольких токенов с различными серверами, даже на уровне проекта;
• Ограничение количества одновременно выполняемых задач для каждого токена;
• Поддержка различных способов выполнения задач: локально, в Docker-контейнерах, через SSH или с автоскейлингом в облаке;
• Кроссплатформенность: GNU/Linux, macOS, Windows;
• Поддержка Bash, PowerShell Core и Windows PowerShell;
• Кастомизация среды выполнения задач;
• Автоматическая перезагрузка конфигурации без остановки Runner.

Как работает Runner

Процесс работы GitLab Runner можно описать следующим образом:

• Регистрируется Runner с использованием registration_token;
• GitLab отправляет задачи на зарегистрированный Runner с помощью job_token;
• Runner выполняет задачу, клонирует источники, скачивает артефакты, обновляет статус выполнения и возвращает результаты в GitLab.

Существует всего два варианта развёртывания Runner:

• GitLab-hosted runners — это раннеры, полностью управляемые GitLab и доступные пользователям на платформе GitLab.com. Их не требуется устанавливать или обслуживать вручную, поскольку GitLab берет на себя все задачи по поддержке и обновлению.
• Self-managed runners — это раннеры, которые устанавливаются и обслуживаются на вашей собственной инфраструктуре. Они требуют ручной настройки и управления, но взамен предоставляют полный контроль над конфигурацией, безопасностью и используемыми ресурсами.

Jenkins

В предыдущих примерах CI/CD мы уже сталкивались с этим инструментом. Jenkins — это сервер автоматизации с открытым исходным кодом, который превращает сборку, тестирование и развёртывание приложений в упорядоченный и управляемый процесс. DevOps-команды используют его, чтобы ускорять работу с проектами, контролировать изменения и легко интегрировать новые инструменты благодаря богатому набору плагинов. Каждое действие в Jenkins можно настраивать под конкретный проект, что делает его гибким и мощным инструментом для реальной разработки.

Пример базового пайплайна Jenkins

pipeline {
    agent any

    stages {
        stage('gitlab') {
            steps {
                echo 'Notify GitLab'
                updateGitlabCommitStatus name: 'build', state: 'pending'
                updateGitlabCommitStatus name: 'build', state: 'success'
            }
        }
    }
}

Токен доступа для GitLab

Для интеграции Jenkins с GitLab необходимо создать токен с правами API. Он позволяет Jenkins авторизоваться и получать события о пушах, merge request и tag push. Токены бывают трех видов:

• Персональный — используется для всех интеграций конкретного пользователя;
• Проектный — ограничен одним проектом;
• Групповой — охватывает все проекты внутри группы.

Установка плагина и подключение к GitLab

На Jenkins-сервере нужно установить gitlab-plugin. После этого в разделе Configure System активируется опция Enable authentication for ‘/project’ end-point для использования токена доступа. URL GitLab указывается в настройках плагина, затем соединение тестируется.

# Установка плагина через интерфейс Jenkins:
Manage Jenkins → Manage Plugins → Available → gitlab-plugin → Install

# Настройка токена:
Manage Jenkins → Configure System → GitLab
Enable authentication for '/project' end-point
Добавить GitLab API Token → вставить значение токена
GitLab host URL → вставить URL GitLab
Test Connection

Создание проекта

Проект создается через New Item. Для классических сборок выбираем Freestyle, для скриптовых пайплайнов — Pipeline. Подключаем GitLab через токен, активируем триггер «Build when a change is pushed to GitLab», а в Freestyle-проектах добавляем Post-build Action Publish build status to GitLab. Для Pipeline используется скрипт, который обновляет статус коммита.

pipeline {
    agent any
    stages {
        stage('Notify GitLab') {
            steps {
                echo 'Отправка статуса в GitLab'
                updateGitlabCommitStatus name: 'build', state: 'pending'
                updateGitlabCommitStatus name: 'build', state: 'success'
            }
        }
    }
}

Конфигурация GitLab

На стороне GitLab открываем проект → Settings → Integrations → Jenkins. Активируем интеграцию, указываем события для сборки (push, merge request, tag push), URL Jenkins и имя проекта. При необходимости добавляем логин и пароль. Перед сохранением проверяем соединение кнопкой Test settings.

Альтернатива: использование Webhook

Если прямое подключение к Jenkins невозможно, можно использовать webhook. В Jenkins создается Secret Token для задачи, который вставляется в GitLab при создании вебхука. Ссылка имеет вид:

https://JENKINS_URL/project/PROJECT_NAME

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

Отладка и логирование

При проблемах с интеграцией GitLab может выдавать ошибки подключения. Чаще всего это связано с недоступностью Jenkins, неверными правами токена или отсутствием разрешений для домена Jenkins в allowlist GitLab. Для детальной диагностики в Jenkins включаем логирование:

# Включение логов:
Dashboard → Manage Jenkins → System Log → Add new log recorder
Логгер: com.dabsquared.gitlabjenkins
Уровень: All

# Просмотр логов:
Run a build → Dashboard → Manage Jenkins → System Log → выбрать созданный логгер

GitFlic

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Сборка проекта"

test-job:
  stage: test
  script:
    - echo "Запуск тестов"

deploy-job:
  stage: deploy
  script:
    - echo "Развёртывание приложения"

branches:
  only:
    - master
    - develop

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Сборка проекта"
    - yarn install
    - yarn build

test-job:
  stage: test
  script:
    - echo "Запуск тестов"
    - yarn test

deploy-job:
  stage: deploy
  script:
    - echo "Развёртывание приложения"
    - scp -r ./build user@server:/var/www/app

variables:
  DOCKER_USERNAME: youruser
  DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
  SERVER_HOST: 192.168.0.100
  DEPLOY_PATH: /var/www/app

trigger:
  on:
    push: true
    merge_request: true
    schedule: "0 3 * * *"

webhook:
  url: "https://example.com/hook"
  events:
    - build_completed
    - deploy_failed

Процессы

CI/CD организует непрерывный поток работы над проектом, разбивая процесс разработки на логические этапы. Такой подход позволяет видеть, как каждая часть работы двигается от идеи до использования конечным пользователем, и помогает оптимизировать все промежуточные шаги.

Процесс CI/CD разработки включает:

• Написание кода. Разработчики создают функциональные модули и проводят первичное локальное тестирование. После проверки изменений они интегрируют свой код в основную ветку, обеспечивая совместимость с текущей версией проекта.
• Автоматическая сборка. Система контроля версий инициирует сборку и автоматическое тестирование проекта. Триггеры могут запускать сборку по пушу в ветку, merge request или по расписанию. Для этого используются инструменты вроде Jenkins или GitLab Runner.
• Дополнительное тестирование. Команда проверяет стабильность новой версии. Тестирование может включать ручные проверки и более глубокий анализ функционала, чтобы убедиться в готовности к релизу.
• Релиз. После выявления и устранения ошибок новая версия готовится к выпуску. Этап фиксирует стабильную версию для конечных пользователей.
• Развёртывание. Готовая версия кода размещается на production-серверах. Пользователи получают доступ к актуальной версии приложения, а команда следит за корректной работой сервиса.
• Поддержка и мониторинг. Продукт активно используется. Разработчики собирают метрики, отслеживают ошибки и анализируют пользовательский опыт для выявления проблем и узких мест.
• Планирование следующего цикла. На основе обратной связи и собранных данных формируются новые задачи и улучшения. Цикл разработки начинается заново, обеспечивая непрерывное совершенствование продукта.

Системы

Подведём итог. Многие из этих инструментов мы уже обсуждали или подробно разбирали ранее, но теперь рассмотрим дополнительные решения, чтобы получить полное представление о современных системах автоматизации.

Все перечисленные платформы широко применяются в индустрии, проверены временем и успешно используются в проектах любого масштаба — от стартапов до крупных корпоративных продуктов. Они позволяют выстраивать прозрачные процессы сборки, тестирования и развертывания, управлять зависимостями и интеграциями с внешними сервисами.

GitLab CI/CD

Инструменты GitLab CI/CD позволяют описывать процессы сборки, тестирования и развертывания через YAML-конфигурации, управлять зависимостями между задачами и связывать пайплайны разных проектов. Решение популярно, подходит для организации комплексных процессов разработки внутри единой платформы.

GitHub Actions

Платформа автоматизации от Git, позволяющая выполнять сборку, тестирование и деплой при изменениях в репозитории. Работает через файлы workflow и поддерживает запуск задач по событиям, таким как push, pull request или расписание.

Jenkins

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

Jenkins X

Расширение Jenkins для Kubernetes, оптимизированное под современные облачные среды и микросервисы.

TeamCity

Коммерческая платформа от JetBrains для CI/CD с фокусом на визуализацию процессов и детальный контроль сборок.

CircleCI

Платформа, оптимизированная на скорость и параллельность выполнения задач, поддерживает облачные и локальные пайплайны.

Travis CI

Лёгкий облачный инструмент, популярный в open-source-сообществе, который ускоряет проверку и деплой проектов.

Bamboo

CI/CD-платформа Atlassian с фокусом на интеграцию с Jira и Bitbucket, удобна для корпоративных процессов.

Azure DevOps

Комплексный набор инструментов от Microsoft с возможностями CI/CD и управления проектами.

GitFlic

Российская платформа для управления репозиториями и CI/CD с полным контролем инфраструктуры.

Автоматизация

CI/CD делает разработку последовательной и предсказуемой. После коммита код автоматически проходит сборку, тестирование и развертывание, а команда может сосредоточиться на доработке и совершенствовании продукта.

Автоматизация позволяет создавать предсказуемые циклы выпуска. Каждое изменение проходит проверку на этапе сборки и тестирования, что ускоряет итерации и упрощает внедрение сложных функций.

Со временем CI/CD становится частью рабочей культуры. Команды быстрее интегрируют изменения, выпускают новые версии по мере необходимости и поддерживают стабильность продукта на протяжении всего цикла разработки.

Чем отличается CI от CD

CI и CD — это два взаимосвязанных, но разных подхода в автоматизации разработки, каждый из которых решает свои задачи.

Continuous Integration (CI), или непрерывная интеграция, сосредоточена на частой проверке и объединении изменений кода. Разработчики регулярно отправляют свои изменения в общий репозиторий, после чего система автоматически собирает проект и выполняет тесты. Это позволяет обнаруживать ошибки на раннем этапе и поддерживать стабильность кода.

Continuous Delivery и Continuous Deployment (CD) выходят за рамки сборки и тестирования. Continuous Delivery гарантирует, что каждая версия кода готова к выпуску в продакшен, но сам процесс развёртывания может запускаться вручную. Основная цель — иметь всегда рабочую и проверенную версию приложения, готовую к релизу в любой момент.

Continuous Deployment же автоматизирует весь путь до продакшена. Каждое изменение, успешно прошедшее тесты, автоматически разворачивается на рабочем сервере.

Заключение

CI/CD (непрерывная интеграция/непрерывная доставка) — достаточно популярная методология, превращающая разработку в последовательный процесс, где код проходит проверку, тестирование и развертывание без хаоса и неожиданностей. Каждый результат изменений фиксируется, что помогает быстро находить и устранять ошибки, делая проекты более управляемыми и прозрачными.

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

Автоматизация CI/CD формирует культуру непрерывной разработки, где обновления интегрируются регулярно, тесты выполняются автоматически, а релизы проходят предсказуемо. Команды развивают продукт быстрее, сохраняя стабильность и уверенность в качестве кода.