ada-pc: 2026-06-16 20:03:28 | 2

Affected files:
90 Library/DevOps/CI-CD — основы.md
99 System/Archive/CI-CD Конвейер для сборки и доставки продукта. Построение пайплайнов.md

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

@@ -1,6 +1,6 @@
 ---
 title: CI/CD — основы
-status: seed
+status: processing
 type: concept
 tags:
   - devops
@@ -8,11 +8,13 @@ tags:
   - gitlab-ci
   - jenkins
 created: 2026-06-12
-updated: 2026-06-12
+updated: 2026-06-16
 aliases:
   - Основы CI/CD
   - Непрерывная интеграция и доставка
-source: "CIСD Конвейер для сборки и доставки продукта. Знакомство с GitlabCI и Jenkins"
+source:
+  - "CIСD Конвейер для сборки и доставки продукта. Знакомство с GitlabCI и Jenkins"
+  - "[[CI-CD Конвейер для сборки и доставки продукта. Построение пайплайнов]]"
 ---
 
 # CI/CD — Основы
@@ -50,6 +52,7 @@ Unit-тесты запускают отдельные единицы кода в
 Delivery и deployment часто обозначают одной аббревиатурой CD, но уровень автоматизации выпуска у них различается.
 
 ![[Pasted image 20260612125409.png]]
+
 ## Пайплайн
 
 **Pipeline** — описанная последовательность стадий и задач CI/CD. Обычно новый запуск инициируется коммитом, merge request, тегом, расписанием или ручным действием.
@@ -68,6 +71,32 @@ Delivery и deployment часто обозначают одной аббреви
 
 Отдельная задача внутри 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
+```
+
 ## Артефакт
 
 **Артефакт** — неизменяемый результат сборки, который можно проверить, хранить и продвигать между средами. Это может быть бинарный файл, пакет, архив или контейнерный образ.
@@ -103,6 +132,17 @@ Pipeline не заканчивается фактом развёртывания
 
 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;
@@ -121,6 +161,19 @@ Jobs выполняются компонентами **GitLab Runner**. Runner
 
 **Jenkins** — самостоятельный open-source сервер автоматизации. Pipeline можно описывать декларативно или программно в `Jenkinsfile` с использованием Groovy.
 
+Для Jenkins важна экосистема плагинов: через них подключаются системы контроля версий, учётные данные, агенты, уведомления, Kubernetes, инструменты безопасности и observability. Плагины упрощают интеграции, но требуют регулярного обновления и контроля совместимости.
+
+Pipeline можно настроить через веб-интерфейс, но для воспроизводимости лучше хранить `Jenkinsfile` в репозитории рядом с кодом. Тогда изменения pipeline проходят тот же контроль, что и изменения продукта: review, merge request, история коммитов и ограничения доступа.
+
+Запуск Jenkins pipeline возможен:
+
+- вручную через веб-интерфейс или API;
+- автоматически через интеграции и плагины;
+- через webhook из GitLab или другой VCS-платформы;
+- по расписанию.
+
+При описании pipeline на Groovy Jenkins может генерировать фрагменты синтаксиса через встроенный помощник. Это снижает риск ошибки при работе с параметрами шагов и плагинов.
+
 Преимущества:
 
 - большая экосистема плагинов;
@@ -135,6 +188,19 @@ Jobs выполняются компонентами **GitLab Runner**. Runner
 - конфликты версий и накопление плагинов усложняют обновления;
 - для небольших команд эксплуатация может быть тяжелее встроенного решения.
 
+## Развитие 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 |
@@ -153,5 +219,6 @@ Jobs выполняются компонентами **GitLab Runner**. Runner
 - [[DevOps - основы]]
 - [[Git]]
 - [[Gitlab]]
+- [[IaC - основы]]
 - [[Основы - Docker]]
 - [[Kubernetes - MOC]]