Стадии конвейера — Примеры

Пример 1 — Порядок стадий по скорости обратной связи

Конвейер запускает весь сквозной набор, затем проверку стиля, затем сборку — на каждое изменение. Изменение с очевидной синтаксической ошибкой ждёт своего ответа двенадцать минут. Переставьте стадии так, чтобы самый дешёвый вопрос задавался первым, и уберите медленный набор с быстрого пути.

jobs:
  verify:
    steps:
      - run: run-end-to-end-suite    # 12 мин, на каждое изменение
      - run: check-formatting        # 5 с
      - run: build-artifact          # 2 мин

Решение

jobs:
  check:
    steps:
      - run: check-formatting        # секунды; отсеивает большинство плохих изменений
  test:
    steps:
      - run: run-unit-tests          # минуты; на каждое изменение
  build:
    needs: [check, test]
    steps:
      - run: publish-artifact-version   # один раз, с версией
  e2e:
    needs: [build]
    steps:
      - run: run-end-to-end-suite     # перед развёртыванием, не на каждый коммит

Теперь каждая стадия отвечает на один вопрос — верно ли это по форме, работает ли так, как надо, можно ли это упаковать, запускается ли это здесь, — поэтому провал называет вопрос, а не смешивает три. Дешёвая проверка отвечает за секунды, и именно это держит цикл достаточно коротким, чтобы реагировать; медленный набор всё равно выполняется, но перед развёртыванием, а не на каждом коммите. Ошибка — оставить медленный набор первым, потому что это самый ценный тест: ценность и скорость — разные решения, а порядок стадий — экономическое.

Пример 2 — Собрать один раз и продвинуть одну версию

Две стадии развёртывания пересобирают приложение из исходников, поэтому то, что проверил staging, не совсем то, что получает продакшен. Измените конвейер так, чтобы один версионированный артефакт продвигался в оба окружения, а решение о выпуске оставалось отдельно от результата тестов.

staging:    build -> deploy   (пересборка из исходников)
production: build -> deploy   (пересборка из исходников)

Решение

build      -> артефакт myapp, версия 482
staging    -> deploy версии 482          (без шага сборки)
production -> deploy версии 482          (с подтверждением)

rollback   -> повторный deploy версии 481 из того же хранилища артефактов

Сборка один раз и продвижение по версии означают, что байты, прошедшие staging, — это и есть выпущенные байты, а любая пересборка возвращает различия, ради устранения которых конвейер и существует. Развёртывание, оставленное отдельной стадией с подтверждением, делает зелёную сборку доказательством, а не разрешением выпускать. Ошибка — пересобирать для каждого окружения «на всякий случай», и именно это заставляет протестированный артефакт и выпущенный расходиться.