SecondBrain/90 Library/DevOps/CI-CD — основы.md

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

title	status	type	tags	created	updated	aliases	source
CI/CD — основы	processing	concept	devops cicd gitlab-ci jenkins	2026-06-12	2026-06-16	Основы CI/CD Непрерывная интеграция и доставка	CIСD Конвейер для сборки и доставки продукта. Знакомство с GitlabCI и Jenkins CI-CD Конвейер для сборки и доставки продукта. Построение пайплайнов

CI/CD — Основы

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

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

Состав CI/CD

Continuous Integration

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

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

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

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

Continuous Delivery

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

!Pasted image 20260612125256.png

Continuous Deployment

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

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

!

Пайплайн

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

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

1. получение исходного кода;
2. линтинг и статический анализ;
3. модульное и интеграционное тестирование;
4. сборка приложения;
5. упаковка артефакта, например контейнерного образа на основе Основы - Docker;
6. публикация артефакта;
7. развёртывание;
8. дополнительные проверки;
9. сбор метрик и обратной связи.

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

Stages задают крупные фазы процесса, например build, test, deploy. Jobs внутри разных stages обычно выполняются последовательно по порядку стадий, а несколько jobs внутри одной stage могут выполняться параллельно, если есть свободные исполнители.

Минимальный пример .gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - make build

test-job:
  stage: test
  script:
    - make test

deploy-job:
  stage: deploy
  script:
    - make deploy

Артефакт

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

Один и тот же проверенный артефакт желательно последовательно использовать во всех средах. Повторная сборка перед 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.

Конфигурация GitLab CI/CD сочетает декларативный YAML и команды shell. YAML описывает stages, jobs, переменные, зависимости и условия запуска. Shell-команды внутри script выполняют конкретные действия: сборку, тесты, публикацию артефактов или деплой.

Pipeline можно запускать:

• вручную через веб-интерфейс или API;
• автоматически по push, commit, merge request, tag и другим событиям;
• через webhook или интеграцию с внешней системой;
• с параметрами: переменными, выбранной веткой, тегом, коммитом или окружением.

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

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

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

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

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

Jenkins

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

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

Pipeline можно настроить через веб-интерфейс, но для воспроизводимости лучше хранить Jenkinsfile в репозитории рядом с кодом. Тогда изменения pipeline проходят тот же контроль, что и изменения продукта: review, merge request, история коммитов и ограничения доступа.

Запуск Jenkins pipeline возможен:

• вручную через веб-интерфейс или API;
• автоматически через интеграции и плагины;
• через webhook из GitLab или другой VCS-платформы;
• по расписанию.

При описании pipeline на Groovy Jenkins может генерировать фрагменты синтаксиса через встроенный помощник. Это снижает риск ошибки при работе с параметрами шагов и плагинов.

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

• большая экосистема плагинов;
• интеграция со множеством систем контроля версий, сборки и развёртывания;
• гибкость при построении нестандартных процессов;
• развитое сообщество и документация.

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

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

Развитие CI/CD

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

Практики, которые усиливают CI/CD:

• IaC - основы — декларативное описание инфраструктуры и конфигурации;
• контейнеризация через Основы - Docker и оркестрация через Kubernetes - MOC;
• observability: метрики, логи, трассировки, аудит, обработка логов и обратная связь;
• DevSecOps-проверки: SAST, SCA, DAST, IAST, RASP, сканирование инфраструктуры и работа с секретами.

Эти проверки можно добавлять как отдельные stages или jobs. Главное - не превращать pipeline в непрозрачный набор ручных действий: сборка, тесты, доставка и контроль качества должны быть описаны как код и воспроизводиться одинаково.

GitLab CI/CD и Jenkins

Критерий	GitLab CI/CD	Jenkins
Модель	Встроен в GitLab	Самостоятельный сервер
Описание pipeline	YAML	Jenkinsfile, Groovy
Исполнители	GitLab Runner	Jenkins agents
Интеграции	Нативные возможности GitLab	Обширная система плагинов
Сопровождение	Зависит от способа размещения GitLab и runners	Требует сопровождения controller, agents и плагинов
Основной сценарий	Проекты, уже использующие GitLab	Гетерогенная инфраструктура и нестандартные интеграции

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

Связанные заметки

• DevOps - основы
• Git
• Gitlab
• IaC - основы
• Основы - Docker
• Kubernetes - MOC