На хакерньюс и в силиконовой долине в целом набирает популярность полностью вырезать Dev/Staging/UAT окружения из процесса разработки и деплоить в продакшен сразу после мерджа.
А всё тестирование проводить либо под флагами, либо деплоить бранчи и давать QA доступы только в ветку вместо какого-то общего стейджа/UAT. То есть, понятие предрелизного смоуктеста как и самого релиза исчезает.
Мы сейчас в стартапе на той стадии развития, когда появляются и первые платящие клиенты, и первые наемные сотрудники.
Нужно принимать решения про организацию процесса релиза, тестирования и выхода в прод новых фич. Проект — монорепо с несколькими разными бекендами и несколькими фронтендами, объединенными общей дб с миграциями и общими типами в NX.
Что бы вы сделали в полностью новой компании? Какие аргументы за и против?
за «Дев/стейджинг окружение»
за «Деплой в продакшен напрямую»
Кто в Прод деплоит по утрам,
Тот поступает мудро!
Конфиг забыли, и к херам
Сломали прод за утро!
Скучна вечерняя пора,
Разрабы все зевают
Но если прод сломать с утра
Такого не бывает!
Процесс с девом/стейджингом/продом понятен всем, предсказуем, позволяет так же делать некоторое количество экспериментов, не боясь за состояние продакшена.
Да, мы платим за дополнительное железо, но таки ли много будет платить ваш стартап за копию продакшена для тестов? Думаю, что нет.
«Но в Гугл/Фейсбук/ЕТЦ же нету девелопа, гонят сразу в прод!»
Хорошо. А у вас есть бюджеты Гугла? Специалисты уровня Гугла? Доверие пользователей, как у Гуглу? Нет? Тогда нахера вам делать как в Гугле?
Представьте себе ситуацию: кто-то задеплоил в прод и снес его к хуям, причем весь и так, что не восстановить. Ваши действия? Если действие «рвать волосы на жопе» - сделайте девелоп, не выпендривайтесь.
На стейдже можно творить любую дичь, иметь неконсистентные данные в тестовых целях и все такое. Условно, быстро создать в системе заказ в статусе "доставлено" и потыкать веточкой, не проводя его по всем корректным процедурам.
На продакшене все должно быть обмазано валидациями и защитами от дурака, и тестировать в таких условиях станет сложно, либо придется протаскивать какие-то обходные пути и надеяться, что они не выстрелят в каком-то неожиданном месте.
Теперь про мой опыт: уже больше года назад включили авторелизы мастера после мержа, критичных падений за это время был всего один, в среднем около 3-4 релизов в неделю. Недописанные фичи закрываются фича флагом, то, что еще не должно быть на проде закрываются фича флагами, первое время команда боялась, но адаптировались и кайфуем. Попробуйте и вы
Чего тестировать-то)
Примечания:
Деплой напрямую в прод максимально вреден.
Стейдж окружение необязательно может быть дорогим: множеству проектов достаточно docker compose с некоторыми отличиями из-за особенностей конкретного проекта.
Да, какие-то пограничные кейсы выловить так не получится, плюс регулярно нужно накатывать БД с прода(с анонимизацией ПД). Но для удобного тестирования продуктовых фич для релиза хватит и этого.