Варианты рабочих процессов | Построение процесса CI/CD | Rails

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

Готовые конфигурации рабочего процесса

№1 Fast and Furious

Конфигурация рекомендована в качестве наиболее соответствующей канонам CI/CD, которую можно реализовать с помощью werf.

В данной конфигурации может быть произвольное число production-like окружений, как то: testing, staging, development, qa, и т.д.

Окружение	Блок рабочего процесса
Production	Развёртывание на production из master автоматически + откат через revert
Staging / Testing / Development / QA	Развёртывание на production-like из pull request по кнопке
Review	Развёртывание на review из pull request автоматически после ручной активации

№2 Push the button

Окружение	Блок рабочего процесса
Production	Развёртывание на production из master по кнопке
Staging	Развёртывание на staging из master автоматически
Testing / Development / QA	Развёртывание на production-like из ветки автоматически
Review	Развёртывание на review из pull request по кнопке

№3 Tag everything

Не все проекты сходу готовы к внедрению CI/CD. В таких проектах используется более классический метод создания релизов только после активной фазы разработки. Переход к CI/CD в таких проектах требует усилий по преодолению привычных вещей и переосмысления как от разработчиков, так и от DevOps. Поэтому для таких проектов мы предлагаем и классическую конфигурацию, которая также рекомендована для werf в случае невозможности использования fast & furious.

Окружение	Блок рабочего процесса
Production	Развёртывание на production из тега автоматически
Staging	Развёртывание на staging из master автоматически или развёртывание на staging из master по кнопке
Review	Развёртывание на review из pull request автоматически после ручной активации

№4 Branch, branch, branch

Управляем развёртыванием прямо через Git с использованием веток и процедур Git merge, rebase и push-force. Через создание определённых имен веток получаем автоматическое развёртывание на review окружения.

Рекомендуем для тех, кто хочет управлять CI/CD полностью из git. Отметим, что подход также является соответствующим канонам CI/CD, как и fast & furious.

Окружение	Блок рабочего процесса
Production	Развёртывание на production из master автоматически + откат через revert
Staging	Развёртывание на staging из master автоматически
Review	Развёртывание на review из ветки по шаблону автоматически

Варианты организации развёртывания для различных окружений

Развёртывание на production

Из master ветки

Автоматически

Merge или коммит в ветку master вызывает pipeline развёртывания непосредственно на production.

Состояние ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).

По кнопке

Pipeline развёртывания в production может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API.

Варианты отката:

Рекомендованный: средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката.

Из произвольной ветки

Автоматически

Merge или коммит в специальную ветку вызывает pipeline развёртывания непосредственно на production (вариант похож на master-автоматически, но используется отдельная ветка).

Состояние специальной ветки в любой момент времени отражает состояние окружения. Поэтому данный вариант является соответствующим подходу true CI/CD.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в master, затем fast-forward merge в специальную ветку.
Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force).

По кнопке

Pipeline развёртывания в production может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API.

Варианты отката:

Рекомендованный: средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта master-автоматом), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката.

Из тега

Автоматически

Создание нового тега автоматически вызывает pipeline развёртывания на production-окружение из коммита, связанного с этим тегом.

Варианты отката:

Рекомендованный: средствами CI/CD системы, повторный ручной вызов pipeline на старом теге.
Создание нового тега на старый коммит, далее автоматический вызов pipeline развёртывания для нового тега. Не предпочтительный вариант, т.к. плодятся лишние теги.

По кнопке

Pipeline развёртывания в production-окружение может быть вызван только на существующем теге в git. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API.

Варианты отката:

Средствами CI/CD системы, повторный ручной вызов pipeline на старом теге.

Развёртывание на production-like

Из pull request

По кнопке

Pipeline развёртывания в production может быть запущен на любом коммите в pull request. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API.

Варианты отката:

Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).

Из ветки

Автоматически

Merge или коммит в специальную ветку вызывает pipeline развёртывания непосредственно на production-like окружение (вариант похож на master-автоматически, но используется отдельная ветка). Для каждого конкретного production-like окружения, как то: staging или testing — используется отдельная ветка.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в master, затем fast-forward merge в специальную ветку.
Удаление коммита в специальной ветке (через удаление коммита в git, затем процедура git push-force).

Пример рабочего процесса для staging

Merge или коммит в ветку master вызывает pipeline развёртывания непосредственно на staging окружение.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке master. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).

По кнопке

Pipeline развёртывания в production-like окружение может быть запущен вручную только на коммите из специальной ветки. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API.

Варианты отката:

Рекомендованный: средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от варианта «Развёртывание на production-like из ветки автоматически»), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката.

Пример рабочего процесса для staging

Pipeline развёртывания в staging может быть запущен вручную только на коммите из ветки master. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API.

Варианты отката:

Рекомендованный: средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в ветке master, затем запуск pipeline средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние мастера не всегда соответствует состоянию окружения (в отличие от варианта «Развёртывание на staging из master автоматически»), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката.

Развёртывание на review

Из pull request

Автоматически

Создание pull request автоматически вызывает развёртывание в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают развёртывание в review окружение.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).

Удаление review-окружения:

По закрытию или принятию PR.
Автоматически по истечению time-to-live с последнего развёртывания на данное окружение (другими словами, при отсутствии активности в данном окружении).

Автоматически после ручной активации

Review-окружение для pull request создаётся после его ручной активации средствами CI/CD системы. С этого момента любой коммит в ветку, связанную с pull request, вызывает автоматическое развёртывание на review окружение. После работы с review его можно деактивировать вручную средствами CI/CD системы.

Pipeline развёртывания в review-окружение может быть запущен только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline для активации review окружения производится средствами CI/CD системы вручную: кнопка в CI/CD системе, повесить label или вызов API.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).

Удаление review-окружения:

Запуск pipeline для деактивации review окружения средствами CI/CD системы вручную: кнопка в CI/CD системе, снять ранее повешенный label или вызов API.
По закрытию или принятию PR.
Автоматически по истечению time-to-live с последнего развёртывания на данное окружение (другими словами, при отсутствии активности в данном окружении).

По кнопке

Pipeline развёртывания в review-окружение может быть запущен вручную только на коммите из ветки соответствующей этому окружению. Название этого окружения связано с именем ветки. Запуск pipeline производится средствами CI/CD системы вручную: кнопка в CI/CD системе, повесить label или вызов API.

Варианты отката:

Рекомендованный: средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).
Реверт коммита в ветке, затем запуск pipeline средствами CI/CD системы вручную: кнопка в CI/CD системе или вызов API. В данном случае вариант не рекомендован, т.к. состояние ветки не всегда соответствует состоянию окружения (в отличие от вариантов “автоматом для pull-request” и “автоматом для pull-request по паттерну”), поэтому создавать лишний revert не имеет большого смысла именно для задачи отката.

Удаление review-окружения:

По закрытию или принятию PR.
Автоматически по истечению time-to-live с последнего развёртывания на данное окружение (другими словами, при отсутствии активности в данном окружении).

Из ветки

Автоматически

Создание pull request для ветки, подходящей под определённый паттерн автоматически вызывает развёртывание в отдельное review окружение. Название этого окружения связано с именем ветки. Дальнейшие коммиты в ветку, связанную с pull request автоматически вызывают развёртывание в review окружение.

Например, для паттерна review_* создание pull request для ветки review_myfeature1 вызовет автоматическое создание соответствующего review окружения.

Варианты отката:

Рекомендованный: откат через реверт коммита в ветке. В этом случае поддерживается состояние ветки в синхронизированном с окружением состоянии, поэтому это предпочтительный вариант для сохранения целостности схемы.
Средствами CI/CD системы, повторный ручной вызов pipeline на старом коммите (например, в GitLab CI кнопка “откатить” по факту выполняет именно эти шаги).

Удаление review-окружения:

По закрытию или принятию PR.
Автоматически по истечению time-to-live с последнего развёртывания на данное окружение (другими словами, при отсутствии активности в данном окружении).