Files

T

Dmitry 4c394b3f6b ada-pc: 2026-06-12 11:25:50 | 3

Affected files:
90 Library/DevOps/CI-CD — основы.md
99 System/Archive/CIСD Конвейер для сборки и доставки продукта. Знакомство с GitlabCI и Jenkins.md
99 System/INDEX.md

2026-06-12 11:25:50 +03:00

9.7 KiB

Raw Blame History

title, status, type, tags, created, updated, aliases, source

title

status

type

CI/CD — основы

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

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

Состав CI/CD

Continuous Integration

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

Типичный CI-процесс:

Разработчик отправляет изменения в репозиторий.
Система запускает статический анализ и автоматические тесты.
Приложение собирается или компилируется.
Результат упаковывается в версионированный артефакт.
Артефакт сохраняется в реестре или хранилище.

Unit-тесты запускают отдельные единицы кода в контролируемом окружении. Кроме них в CI могут входить линтеры, SAST, SCA, интеграционные тесты и проверки качества.

Continuous Delivery

Continuous Delivery — поддержание проверенного артефакта в состоянии готовности к выпуску. Доставка до production обычно требует явного решения или ручного подтверждения.

Continuous Deployment

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

Delivery и deployment часто обозначают одной аббревиатурой CD, но уровень автоматизации выпуска у них различается.

Пайплайн

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

Распространённые стадии:

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

Отдельная задача внутри pipeline обычно называется job. Jobs объединяются в stages и выполняются на выделенных исполнителях.

Артефакт

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

Один и тот же проверенный артефакт желательно последовательно использовать во всех средах. Повторная сборка перед production создаёт риск получить результат, отличный от протестированного.

Среды

Продукт проходит через несколько изолированных сред:

Dev — разработка и ранняя интеграция;
Test / QA / Integration — функциональные и интеграционные проверки;
Stage / Pre-production / UAT — проверка в окружении, близком к production;
Prod — эксплуатация продукта пользователями.

Развёртывание может выполняться на виртуальных машинах, в контейнерах или в оркестраторе, например Kubernetes - MOC.

Обратная связь

Pipeline не заканчивается фактом развёртывания. После выпуска необходимо собирать:

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

Эти данные возвращаются в цикл разработки и помогают оценить качество релиза. Наблюдаемость pipeline также показывает длительность задач, частоту сбоев и узкие места доставки.

GitLab CI/CD

GitLab CI/CD — встроенная в Gitlab система автоматизации pipeline. Конфигурация обычно хранится рядом с кодом в файле .gitlab-ci.yml.

Jobs выполняются компонентами GitLab Runner. Runner может работать на физическом сервере, виртуальной машине, в Docker или Kubernetes.

Преимущества:

тесная интеграция с репозиториями, merge request и правами GitLab;
pipeline as code;
управление jobs, stages, артефактами и окружениями в одном интерфейсе;
просмотр состояния и результатов задач;
возможность масштабирования runners.

Ограничения:

наиболее удобен внутри экосистемы GitLab;
сложные pipeline требуют аккуратной организации YAML-конфигурации;
поведение артефактов, cache и зависимостей между jobs необходимо явно проектировать.

Jenkins

Jenkins — самостоятельный open-source сервер автоматизации. Pipeline можно описывать декларативно или программно в Jenkinsfile с использованием Groovy.