Continuous Delivery. Схема релизов (Prod/Stage/Test/Dev)

Общая информация

Существуют разные стратегии для выстраивания релизного процесса для проекта. Тут мы рассмотрим пару деталей и популярные решения.

Основные принципы Continuous Delivery

Во время разработки Kubernetes-операторов с функционалом Validation/Mutation Webhook вы, скорее всего, столкнетесь с 2 проблемами:

1. Полная автоматизация. Ручные повторяемые действия дорого стоят и приводят к ошибкам. Тесты-релизы-изменение конфигураций, все подобные действия должны быть автоматизированы
2. Воспроизводимость. Выполнив доставку кода на какое-то окружение 1 раз, должны быть уверенность, что выполнение последующей доставки кода приведет к точно тому же результату.
3. Управление версиями. Для контроля добавляемой функциональности к приложениям и возможности быстрого отката к предыдущим версиям приложения

Рекомендации

1. Commit early, commit often. Часто отправляйте коммиты в main-ветку. Чтобы использовать возможности непрерывной интергации необходимо, чтобы все члены команд были согласованы друг с другом. Соответственно реализовав какой-то функционал - желательно сразу после тестов слить его с main-веткой. Необходимо это для согласованности, чтобы каждый разработчик работая над задачей мог подuрузить актуальной состояние main-ветки и убедиться, что его изменения согласуются с актуальным состоянием кодовой базы.
2. Build only once. Один билд для всех окружений! Выполнив билд проекта для тестового окружения не нужно перебилживать его для прод-окружения
3. Clean your environments. Когда какая-то среда работает в течении длительного времени - высока вероятность, что она начнет сильно разъезжаться с Prod-средой. Соответственно не нужно постоянно держать какое-то окружение активным. Лучше наладить динамической развертывание окружений.

DevOps Branching Strategy (Feature branching)

Релизные модели используемые в компаниях часто перетекают от подхода к ведению разработки в рамках компании (agile/waterfal/scrum). Однако самый популярный и зарекомендовавший себя подход - DevOps Branching Strategy (или же Feature branching). Основа концепции заключается в том, что есть стабильная ветка и различные ветки, в которых ведется разработка определенных фич или набора фич. Каждая ветка перед слиянием в main тестируется и проверяется QA. Есть несколько стратегий ветвления (их больше, но эти 3 самые популярные)

GitFlow

Есть 2 основные ветки - main и develop. Вся разработка ведется в develop-ветке всей командой. Перед релизом инициируется Merge Request и develop-ветка сливается в main. Плюсы:

• Простота. Идеально для проекта, над которым работает 1 человек. Минусы:
• Практически неприменимо для больших и сложных проектов с большой командой разработчиков

Зеленые кружочки в названии ветки обозначает, что для этой ветки разворачивается полноценное окружение в инфраструктуре.

GitHub Flow

Есть 1 основная ветка - main. Каждая фича (или набор фич) разрабатывается в отдельной ветке. Перед релизом все ветки с нужными фичами вливаются в main-ветку. Минусы:

• Практически невозможно поддерживать несколько версий кода.
• Велика ошибка слияния фичи-ветки и main- ветки.
• Непонятно как производить тестирование команде QA. Либо каждой отдельной фичи в отдельной фича-ветке либо в main после слияния, но перед релизом

GitLab Flow

Что-то общее между GitFlow и GitHub Flow. Есть main-ветка, в которой находится актуальное состояние кода, которое работает в продакшн среде. Есть develop-ветка, в которую разработчики отправляют Merge Requests новых фич со своих фича-веток. Между ветками main и develop можно настроить несколько веток-окружений (stage/test и т.д.), которые могут работать как параллельно, так и последовательно. Плюсы:

• Удобно передавать на тесты develop/stage/test ветки с несколькими реализованными фичами или разными версиями приложения Минусы:
• Сложно в настройке динамичного раскатывания окружения на stage/test ветки

Локальная разработка

Все эти стратегии и вообще все бест-практики подразумевают, что вся разработка происходит локально. Это необходимо, чтобы у каждого разработчика была возможность очень быстро начать локальную разработку без необходимости доступа к инфраструктуре предприятия. + Это значительно снижает нагрузку на инфраструктурные компоненты.

---

На это все. Вы прекрасны :)