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

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

@@ -0,0 +1,154 @@
+---
+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 обычно требует явного решения или ручного подтверждения.
+
+### 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 и выполняются на выделенных исполнителях.
+
+## Артефакт
+
+**Артефакт** — неизменяемый результат сборки, который можно проверить, хранить и продвигать между средами. Это может быть бинарный файл, пакет, архив или контейнерный образ.
+
+Один и тот же проверенный артефакт желательно последовательно использовать во всех средах. Повторная сборка перед 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]]