Dmitry
1b3ccc6f35
Affected files: 90 Library/DevOps/CI-CD — основы.md 99 System/Archive/CI-CD Конвейер для сборки и доставки продукта. Построение пайплайнов.md
225 lines
15 KiB
Markdown
225 lines
15 KiB
Markdown
---
|
|
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]]
|