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

# 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 и выполняются на выделенных исполнителях.

## Артефакт

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

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

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

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

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

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

## 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]]
- [[Основы - Docker]]
- [[Kubernetes - MOC]]