---
title: CI/CD — основы
status: processing
type: concept
tags:
  - devops
  - cicd
  - gitlab-ci
  - jenkins
created: 2026-06-12
updated: 2026-06-16
aliases:
  - Основы CI/CD
  - Непрерывная интеграция и доставка
source:
  - "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|353]]

### Continuous Deployment

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

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

![[Pasted image 20260612125409.png]]

## Пайплайн

**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`:

```yaml
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]]