SecondBrain/00 Inbox/Без названия.md

status, type, tags, created, updated, aliases

status	type	tags	created	updated	aliases
seed	concept		2025-12-17	2026-02-27

Часть 2. Пайплайны в GitlabCI

Пайплайны в GitlabCI строятся на основе языков Shell и Yaml.

С помощью них можно описывать этапы процессов CI/CD и их желаемое поведение.

Язык Yaml позволяет описывать конфигурацию этапов в декларативном ключе.

Основной файл, в котором описывается работа пайплайна, носит название Gitlab-ci.yml.

Shell:

В GitlabCI при описании этапов пайплайна можно задействовать Shell.

Shell — командный интерпретатор операционных систем семейства Unix.

Shell позволяет существенно расширить возможности описания процессов CI/CD.

Stage:

Структура файла Gitlab-ci.yml предполагает разбиение пайплайна на этапы (Stages).

Каждый Stage представляет из себя этап пайплайна с полным описанием его работы.

Этапы (Stages) могут выполняться последовательно или параллельно.

Так могут выглядеть типовые этапы (Stages) в пайплайне GitlabCI.

stages: - build - test - deploy

build-job: stage: build script: - do some build

test-job: stage: test script: - do some test

deploy-job:
     stage: deploy
     script:
          - do some deploy

Запуск пайплайна можно инициировать тремя способами:

• Вручную (через веб-интерфейс или API).
• Автоматически по событию (Push, Commit, Merge-request, etc).
• Используя Web-hook.

Как ручной, так и автоматический запуск пайплайнов может быть дополнительно параметризован при запуске:

• Указание специфических переменных.
• Выбор учетных данных (Credentials).
• Сборка по конкретному коммиту, ветке, тэгу.
• .. и многое другое

Вложенные пайплайны:

В зависимости от сложности процессов CI/CD, пайплайны могут быть составными — содержать вложенные пайплайны, выполняющиеся последовательно или параллельно.

Интеграция:

В случае использования в процессах CI/CD нескольких инструментов, возможна их интеграция (к примеру, исходный код хранится в gitlab, а пайплайны запускаются в Jenkins) через встроенный в GitlabCI механизм интеграций.

GitlabCI имеет понятный веб интерфейс, в котором отображаются результаты прохождения пайплайнов и их отдельных этапов в простом и доступном виде:

Часть 3. Пайплайны в Jenkins

Для полноценной работы Jenkins будет достаточно предустановленных плагинов, но наличие минимально необходимых дополнительных плагинов существенно облегчит построение и модификацию пайплайнов.

Не забывайте своевременно производить обновление используемых плагинов, чтобы избежать ошибок и уязвимостей.

После установки плагина, его требуется настроить для работы, сделать это можно в настройках Jenkins:

• Глобальные настройки.
• Настройки инструментов.
• Настройки безопасности.
• Конфигурирование сред исполнения.

Настройки проекта в Jenkins сводятся к конфигурации самого проекта и его интеграций, а также настройке пайплайна.

Для описания поведения пайплайна мы можем использовать графический интерфейс или язык Groovy.

Если вы испытываете трудности с языком Groovy — вам придет на помощь встроенный редактор запросов.

Сгенерированный запрос можно использовать в описании вашего пайплайна.

Хорошей практикой является описание пайплайна в отдельном файле, который хранится не в Jenkins и подвергается защите от несанкционированного внесения изменений.

Такой файл часто носит название Jenkinsfile и хранится в репозитории (например, в Gitlab), а не в самом Jenkins.

Хранящийся в репозитории Jenkinsfile, вместе с самим исходным кодом продукта, защищен от изменений (их могут вносить только уполномоченные члены команды или с использованием процедуры Merge-request).

Инициировать процедуру запуска пайплайна можно несколькими способами:

• Вручную (веб-интерфейс или API).
• Автоматически, с использованием интеграций (посредством плагинов).
• Используя Web-hook.
• С помощью планировщика сборок.

Имея опыт работы с языком Groovy, используя разнообразные плагины и следуя хорошим практикам организации пайплайнов, можно добиться грамотного построения процессов CI/CD:

• Параметризованные сборки.
• Хранение Jenkinsfile в репозитории с ограничением на изменение.
• Интеграция с Git, Kubernetes, Инструментами обеспечения информационной безопасности и Observability.
• Отказоустойчивая и безопасная конфигурация доступа к Jenkins для других инструментов.
• Визуализация процессов.

Часть 4. Внедрение и развитие процессов CI/CD

Внедрение и развитие процессов CI/CD

В зависимости от того, в каком состоянии находятся существующие процессы разработки, тестирования и администрирования, процессы CI/CD должны внедряться предсказуемо и поэтапно.

Любые существующие процессы CI/CD должны развиваться не прекращаясь.

Обогатить имеющиеся процессы непрерывной сборки и доставки можно следующими практиками:

• IaC.
• Orchestration.
• Observability.
• Info-security.

При настройке процессов непрерывной доставки используйте подход декларативного описания инфраструктуры и конфигурации в виде кода (практики IaC).

Старайтесь придерживаться микросервисной архитектуры там, где это оправдано.

Ориентируйтесь на контейнерные технологии.

Изучайте и применяйте технологии оркестрации контейнерных и неконтейнерных рабочих нагрузок в режиме кластера.

Не пренебрегайте развитием практик обеспечения Observability:

• Мониторинг.
• Трассировки.
• Аудит.
• Журналирование.
• Обработка логов.
• Сбор обратной связи.

Дополняйте этими практиками этапы своих пайплайнов, или добавляйте новые этапы на их основе.

Существующие практики CI/CD можно и нужно обогащать внедрением проверок по информационной безопасности из методологии Devsecops:

• Различные виды анализа (SAST, SCA, DAST, IAST, RASP).
• Сканирование инфраструктуры.
• Использование профильных инструментов для работы с сенсетивной информацией.

Помните о том, что процессы CI/CD — это лишь одна из множества Devops-практик, которые важно и нужно применять для создания благоприятной атмосферы в коллективной работе над цифровым продуктом.

Devops — это, в первую очередь, культура взаимодействия всех участников жизненного цикла цифрового продукта.