Дев/стейджинг окружение
или
Деплой в продакшен напрямую
 Публичный пост для комнаты «Вайтборд» 18 декабря 2023  319

На хакерньюс и в силиконовой долине в целом набирает популярность полностью вырезать Dev/Staging/UAT окружения из процесса разработки и деплоить в продакшен сразу после мерджа.

А всё тестирование проводить либо под флагами, либо деплоить бранчи и давать QA доступы только в ветку вместо какого-то общего стейджа/UAT. То есть, понятие предрелизного смоуктеста как и самого релиза исчезает.

Мы сейчас в стартапе на той стадии развития, когда появляются и первые платящие клиенты, и первые наемные сотрудники.

Нужно принимать решения про организацию процесса релиза, тестирования и выхода в прод новых фич. Проект — монорепо с несколькими разными бекендами и несколькими фронтендами, объединенными общей дб с миграциями и общими типами в NX.

Что бы вы сделали в полностью новой компании? Какие аргументы за и против?

4 аргумента и 27 плюсиков
за «Дев/стейджинг окружение»
4 аргумента и 17 плюсиков
за «Деплой в продакшен напрямую»
за «Дев/стейджинг окружение»
Очередной культ

У какой-то компании получилось выстроить процессы с минимальными багами, пуша сразу в прод, остальные побежали подхватывать и вещать об этом на конференциях/форумах.

У каждого подхода есть плюсы и минусы, также подходы можно комбинировать.

за «Деплой в продакшен напрямую»
Из мемов, автор не я

Кто в Прод деплоит по утрам,
Тот поступает мудро!
Конфиг забыли, и к херам
Сломали прод за утро!

Скучна вечерняя пора,
Разрабы все зевают
Но если прод сломать с утра
Такого не бывает!

за «Дев/стейджинг окружение»
Работает — не трогай.

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

Да, мы платим за дополнительное железо, но таки ли много будет платить ваш стартап за копию продакшена для тестов? Думаю, что нет.

«Но в Гугл/Фейсбук/ЕТЦ же нету девелопа, гонят сразу в прод!»

Хорошо. А у вас есть бюджеты Гугла? Специалисты уровня Гугла? Доверие пользователей, как у Гуглу? Нет? Тогда нахера вам делать как в Гугле?

Представьте себе ситуацию: кто-то задеплоил в прод и снес его к хуям, причем весь и так, что не восстановить. Ваши действия? Если действие «рвать волосы на жопе» - сделайте девелоп, не выпендривайтесь.

Иногда девелоп и стейджинг окружение может быть чрезмерно дорогим.

  Развернуть 1 комментарий

@Whispered, у стартапа с первыми клиентами?
Сомневаюсь.

  Развернуть 1 комментарий

@urtow, у стартапа с корпоративным продуктом на базе SAP - вполне.

  Развернуть 1 комментарий

@Whispered, SAP не жалко, там можно без стейджинга

  Развернуть 1 комментарий
за «Дев/стейджинг окружение»
Облегчает тестирование

На стейдже можно творить любую дичь, иметь неконсистентные данные в тестовых целях и все такое. Условно, быстро создать в системе заказ в статусе "доставлено" и потыкать веточкой, не проводя его по всем корректным процедурам.

На продакшене все должно быть обмазано валидациями и защитами от дурака, и тестировать в таких условиях станет сложно, либо придется протаскивать какие-то обходные пути и надеяться, что они не выстрелят в каком-то неожиданном месте.

за «Деплой в продакшен напрямую»
Сокращение ТТМ, воспитание ответственности у команды, культура написания тестов
  1. Сокращение ТТМ (Time To Market). Основная причина, ведь чем раньше мы доставим ценность до пользователя, тем больше зарботаем
  2. Воспитание отвественности. "Я не хочу думать, если что то не так, qa найдут на деве багулю и зарепортят, зачем мне лишний раз заморачиваться?". Нееет, так нельзя) Вснгда помни, что твой код сразу окажется на проду, поэтоу проверь и перепроверь все сам, не зря же ты свои какасеки получаешь!
  3. Культура написания тестов. Опять! Твой код сразу в прод. Обезопась себя сейчас и себя будущего, когда будешь это рефакторить и напиши уже эти сраные тесты!

Теперь про мой опыт: уже больше года назад включили авторелизы мастера после мержа, критичных падений за это время был всего один, в среднем около 3-4 релизов в неделю. Недописанные фичи закрываются фича флагом, то, что еще не должно быть на проде закрываются фича флагами, первое время команда боялась, но адаптировались и кайфуем. Попробуйте и вы

А речь про фронт, или у вас весь продукт так в релиз идет?

  Развернуть 1 комментарий

@Maks_fm, лично я внедрял фронт, могу рассказать про него, но так релизится продукт в целом

  Развернуть 1 комментарий
за «Деплой в продакшен напрямую»
Правильно, пользователи протестируют

Чего тестировать-то)

за «Деплой в продакшен напрямую»
  • время жмёт, скорость важнее качества: ряд стартапов, кажется, в rtb-индустрии такое, но точно не знаю
  • денег на стейдж нет – качественный стейдж это x2 к инфраструктурным костам, а автоматизацию PR-серверов пилить и поддерживать в отдельном порядке, если не хероку; опять же, если нужна скорость, а денег не хватает; иногда архитектура накручена монгами-кассандрами, и повторять эти кластера в похожем объеме данных тупо дорого
  • низкая ответственность; денег много на даунтайме не потеряете, юзеры пассивны и не заметят даунтайм 10-15 минут, от вашего софта не зависит жизнь и благополучие людей
  • хорошо работает деплой (без этого каждый рабочий день станет рабской каторгой), особенно часть с миграцией схемы данных в базе
  • некому показывать (нет условного продакта или тестера, которому нужно посмотреть фичу до мержа, сборку/запуск можно и локально проверить)

Примечания:

  1. Continuous Deployment – это не про прямое обновление прода через мэрж в мастер, это про возможность деплоя системы по одной кнопке, ну т.е. по мастеру, но не сразу, а когда надо; когда эту кнопку нажать решает бизнес
  2. Нет прямой зависимости между сокращением TTM и отсутствию стейджа, можно спокойно деплоить в прод по 3 раза в день, если стейдж стабильный и деплой быстрый; а можно страдать и бояться лишний раз обновить прод, если деплой и сами изменения работают плохо

про ответственность поддержу полностью - всё зависит от цены падения прода.

  Развернуть 1 комментарий
за «Дев/стейджинг окружение»
Не будьте наивными

Деплой напрямую в прод максимально вреден.
Стейдж окружение необязательно может быть дорогим: множеству проектов достаточно docker compose с некоторыми отличиями из-за особенностей конкретного проекта.

Да, какие-то пограничные кейсы выловить так не получится, плюс регулярно нужно накатывать БД с прода(с анонимизацией ПД). Но для удобного тестирования продуктовых фич для релиза хватит и этого.

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб