--- status: seed type: concept tags: [] created: 2025-12-17 updated: 2026-02-27 aliases: [] --- ## Часть 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 имеет понятный веб интерфейс, в котором отображаются** **результаты прохождения пайплайнов и их отдельных этапов** **в простом и доступном виде:** ![](https://legacy.merionet.ru/images/devops/images/3758/img_01.png) ## Часть 3. Пайплайны в Jenkins Для полноценной работы Jenkins будет достаточно предустановленных плагинов, но наличие минимально необходимых дополнительных плагинов существенно **облегчит** построение и модификацию пайплайнов. ![](https://legacy.merionet.ru/images/devops/images/3758/img_02.png) Не забывайте своевременно производить обновление используемых плагинов, чтобы избежать ошибок и уязвимостей. ![](https://legacy.merionet.ru/images/devops/images/3758/img_07.png) После установки плагина, его требуется настроить для работы, сделать это можно в настройках Jenkins: - Глобальные настройки. - Настройки инструментов. - Настройки безопасности. - Конфигурирование сред исполнения. ![](https://legacy.merionet.ru/images/devops/images/3758/img_06.png) Настройки проекта в Jenkins сводятся к конфигурации самого проекта и его интеграций, а также настройке пайплайна. Для описания поведения пайплайна мы можем использовать графический интерфейс или язык **Groovy**. ![](https://legacy.merionet.ru/images/devops/images/3758/img_04.png) Если вы испытываете трудности с языком Groovy — вам придет на помощь встроенный редактор запросов. Сгенерированный запрос можно использовать в описании вашего пайплайна. ![](https://legacy.merionet.ru/images/devops/images/3758/img_05.png) Хорошей практикой является описание пайплайна в отдельном файле, который хранится не в Jenkins и подвергается защите от несанкционированного внесения изменений. Такой файл часто носит название Jenkinsfile и хранится в репозитории (например, в Gitlab), а не в самом Jenkins. ![](https://legacy.merionet.ru/images/devops/images/3758/img_03.png) Хранящийся в репозитории Jenkinsfile, вместе с самим исходным кодом продукта, защищен от изменений (их могут вносить только уполномоченные члены команды или с использованием процедуры Merge-request). ![](https://legacy.merionet.ru/images/devops/images/3758/img_08.png) Инициировать процедуру запуска пайплайна можно несколькими способами: - Вручную (веб-интерфейс или API). - Автоматически, с использованием интеграций (посредством плагинов). - Используя Web-hook. - С помощью планировщика сборок. ![](https://legacy.merionet.ru/images/devops/images/3758/img_09.png) Имея опыт работы с языком **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** — это, в первую очередь, культура взаимодействия всех участников жизненного цикла цифрового продукта.