Как организовать процесс автоматизации с использованием модульного подхода в CI/CD?

Модульный подход в CI/CD — это создание библиотек переиспользуемых компонентов, которые инкапсулируют этапы пайплайна. Это превращает пайплайн из монолитного скрипта в сборку из стандартных блоков.

Реализация в разных системах:

• GitLab CI: Используем include для подключения шаблонов из внешних файлов или проектов. Ключевой метод — extends для наследования и переопределения.

  # .gitlab-ci.yml
  include:
    - project: 'platform/devops'
      ref: main
      file: '/ci-templates/security-scan.gitlab-ci.yml'
  
  stages: [build, test, deploy]
  
  build:java:
    extends: .base-build
    variables:
      BUILD_TOOL: "maven"
    script:
      - mvn clean package

• Jenkins Shared Libraries: Общая логика выносится в Groovy-библиотеки в отдельном репозитории. Jenkinsfile становится кратким и декларативным.

  // Jenkinsfile
  @Library('company-ci-libs@v2.0') _
  
  pipeline {
      agent any
      stages {
          stage('Build') {
              steps {
                  buildMaven() // Вызов функции из Shared Library
              }
          }
      }
  }

• GitHub Actions Reusable Workflows: Создаем workflow в отдельном репозитории .github/workflows/, который можно вызывать из других workflow.

  # В основном репозитории .github/workflows/ci.yml
  jobs:
    call-reusable-workflow:
      uses: org/ci-templates/.github/workflows/docker-build.yml@v1
      with:
        image-name: "my-app"

Ключевые выгоды модульности:

1. Стандартизация: Все команды используют одинаковые, проверенные этапы сборки, тестирования и деплоя.
2. Упрощение поддержки: Исправление уязвимости в шаге сканирования кода (trivy) происходит в одном месте — в модуле. Изменение автоматически применяется ко всем пайплайнам.
3. Скорость разработки: Разработчики не пишут CI/CD-скрипты с нуля, а компонуют пайплайн из готовых модулей, указывая только специфичные параметры (имя образа, путь к артефакту).