tgoop.com/rdclr_dev/72
Last Update:
Сколько нужно стендов/энвайроментов в Trunk Based Development подходе
Вы решили попробовать TBD и придумали классную многокомпонентную архитектуру для вашего единорожка. Сколько вам нужно окружений, чтобы все работало как нужно?
🦄 Если у вас возник вопрос, при чем здесь единороги, смотрите предыдущий пост.
В зависимости от вашей философии разработки и готовности экспериментировать, правильным ответом может быть 2️⃣, 3️⃣ или 4️⃣.
Давайте рассмотрим каждый из них.
Но начнем с 1️⃣. Single Environment — вполне себе жизнеспособный подход. В Trunk Based Development основная ветка считается стабильной, новый функционал скрыт фича тогглами, поэтому ничего не мешает жить с одним окружением. При условии, если архитектура вашей системы позволяет гарантировать стабильность транк-веток репозиториев всех компонентов без интеграционных тестов между этими компонентами и без инструментов типа Terraform или Helm для управления инфраструктурой. Ну или у вас огромное количество времени и вычислительных можностей и внутри CI/CD пайплайна вы каждый раз поднимаете мини-энв. Поэтому от сферических единорожков перейдем к реальным. 🌈
2️⃣ окружения. Итак, нам нужно иметь возможность проверять изменения кода до того, как они попали в основную ветку. Очень простой рецепт — вешаем CI триггер на пуллреквесты.
Алгоритм следующий: разработчик создает свою короткоживущую веточку, делает изменения, тестирует их локально. Потом пушит и делает пуллреквест в основную. CI собирает компонент, делает статический анализ (линтер или SonarQube), прогоняет юнит тесты, упаковывает в докер и разворачивает на отдельном стенде (обычно мы называем этот стенд dev или sandbox, давайте и будем называть его песочницей). Тут же в пайплайне запускаются автотесты (для бэкенда достаточно API тестов, для фронтенда тестов в headless браузере). При этом на любом шаге, если что-то сломалось, пайплайн не завершится и песочнца будет сломана. Но откатиться до предыдущего состояния можно, просто сделав реверс пуллреквест.
Если все прошло успешно, это означает, что новые изменения не ломают предыдущей логики, зафиксированной тестами. Разработчик может протестировать новый функционал на стенде, и после этого отправить пуллреквест на ревью.
То есть на ревью попадает пуллреквест, который заведомо ничего не сломает. Поэтому ревьюеры могут сконцентрироваться на проверке бизнес-функционала, а не на отлове возможных несовместимостей. После ревью изменения мерджатся в основную ветку и проходят все те же шаги сборки и регрессии, но уже на втором, боевом стенде. С каждым изменением единорожек эволюционирует.
У предыдущего подхода есть минус. Он защищает нас от того, что сломается автоматизация инфраструктуры и бизнес логика. Но не защитит от некорректных данных в БД, а это иногда становится большой проблемой. В варианте с двумя окружениями второй, стабильный энв содержит и тестовые и продакшн данные. Чтобы физически изолировать их, можно добавить третий стенд. 3️⃣
Итак, первый стенд — sandbox, разработчики могут его ломать и экспериментировать еще до ревью
Второй — test, он содержит код, собранный из основных веток, но он предназначен только для тестирования нового функционала. Теоретически на нем можно сломать данные, тестируя какие-нибудь негативные сценарии (А что будет, если напоить единорога самогоном вместо утренней росы? 🤮)
Третий — prod, и там разворачиваются те же самые артефакты, что были собраны на предыдущем шаге. При этом хорошей практикой считается раскатывать сюда новую версию сервиса, как только она прошла авторегрессию на тесте. Мы все еще находимся в парадигме Continuous Deployment и Shift Right (см предыдущий пост), но тестовое окружение физически отделено от продакшена.
Какой подход вам нравится больше всего?
#rdclr_backend #rdclr_frontend #product
BY RDCLR.DEV
Share with your friend now:
tgoop.com/rdclr_dev/72