Какие типы пайплайнов настраивал с помощью Jenkins?

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

1. Declarative Pipeline (Декларативный): Это мой основной выбор для большинства проектов благодаря чёткой структуре и встроенным best practices. Он использует директиву pipeline и предопределённые секции.

   // Jenkinsfile
   pipeline {
       agent any
       options {
           timeout(time: 1, unit: 'HOURS')
       }
       stages {
           stage('Checkout') {
               steps {
                   checkout scm
               }
           }
           stage('Build & Test') {
               parallel {
                   stage('Unit Test') {
                       steps {
                           sh './gradlew test'
                       }
                   }
                   stage('Integration Test') {
                       steps {
                           sh './gradlew integrationTest'
                       }
                   }
               }
           }
           stage('Build Docker Image') {
               steps {
                   script {
                       docker.build("my-app:${env.BUILD_NUMBER}")
                   }
               }
           }
       }
       post {
           always {
               junit '**/build/test-results/test/*.xml'
           }
           success {
               echo 'Pipeline succeeded!'
           }
       }
   }

2. Scripted Pipeline (Скриптовый): Использовал в legacy-проектах или для задач, требующих максимальной гибкости и сложной логики, которую сложно выразить в Declarative-синтаксисе. Основан на Groovy-скриптах.

   node('docker-agent') {
       stage('Checkout') {
           checkout scm
       }
       stage('Build') {
           def builder = docker.build('my-app')
           builder.inside {
               sh 'make all'
           }
       }
   }

3. Multibranch Pipeline: Настраивал для проектов с Git-flow или GitHub Flow. Jenkins автоматически обнаруживает ветки и Pull Request'ы в репозитории и создаёт для них отдельные пайплайны. Это идеально для реализации CI, где каждая ветка и PR автоматически проверяются.

4. Pipeline как код (Jenkinsfile в SCM): Все перечисленные выше пайплайны хранил в файле Jenkinsfile в корне репозитория. Это обеспечивало версионирование, код-ревью конфигурации CI/CD и возможность быстрого восстановления или переноса пайплайна.