SP
если у тебя тестирование руками то не особо важно ветки или конфиги - будут проблемы
Size: a a a
2020 August 04
SP
если у тебя 3 джуна которые чет делают - то возможно ветки будут проще. думаю где-то после 5ти джунов каждый из которых свои штуки мерджит уже будут пробелмы
SP
почему - гуглить зачем придумали континиус интегрейшенс и откуда там правило про "интегрировать изменения как можно быстрее"
VS
Я у себя так сделал, если происходит пуш в ветку rc, то CI её автоматически деплоид на прод и ветку rc убивает.
Помогает уменьшить количество bugfix коммитов в мастере)
В идеале я себе это вижу так - CI деплоит новое окружение и переключает на него трафик не убивая окружение мастера.
Далее смотришь в логи, если повалили ошибки, кнопку отката, трафик переключается обратно на рабочий код.
В идеале конечно и откат чтобы был автоматический, типа как sentry отслеживает с какого релиза были ошибки, если ошибка новая - сразу откат.
Ну это так, мои влажные фантазии
Помогает уменьшить количество bugfix коммитов в мастере)
В идеале я себе это вижу так - CI деплоит новое окружение и переключает на него трафик не убивая окружение мастера.
Далее смотришь в логи, если повалили ошибки, кнопку отката, трафик переключается обратно на рабочий код.
В идеале конечно и откат чтобы был автоматический, типа как sentry отслеживает с какого релиза были ошибки, если ошибка новая - сразу откат.
Ну это так, мои влажные фантазии
А как быть с БД? Если там есть неоткатываемые изменения? Типа drop column?
I
если у тебя 3 джуна которые чет делают - то возможно ветки будут проще. думаю где-то после 5ти джунов каждый из которых свои штуки мерджит уже будут пробелмы
я собственно также думал, просто уровень еще не позволяет идти в это. Спасибо за инфу
SP
А как быть с БД? Если там есть неоткатываемые изменения? Типа drop column?
не делать дроп колумн)
КГ
А как быть с БД? Если там есть неоткатываемые изменения? Типа drop column?
Аккуратнее быть.
Вообще должен быть регрессный тест, который тестирует что старый код способен работать с новыми миграциями.
Как минимум потому что у тебя миграции и запуск кода не происходят одновременно и желательно сначала накатить миграции, и только потом спокойной запустить новый код.
Ибо новый код без новых миграций точно не заработает
Вообще должен быть регрессный тест, который тестирует что старый код способен работать с новыми миграциями.
Как минимум потому что у тебя миграции и запуск кода не происходят одновременно и желательно сначала накатить миграции, и только потом спокойной запустить новый код.
Ибо новый код без новых миграций точно не заработает
AD
Аккуратнее быть.
Вообще должен быть регрессный тест, который тестирует что старый код способен работать с новыми миграциями.
Как минимум потому что у тебя миграции и запуск кода не происходят одновременно и желательно сначала накатить миграции, и только потом спокойной запустить новый код.
Ибо новый код без новых миграций точно не заработает
Вообще должен быть регрессный тест, который тестирует что старый код способен работать с новыми миграциями.
Как минимум потому что у тебя миграции и запуск кода не происходят одновременно и желательно сначала накатить миграции, и только потом спокойной запустить новый код.
Ибо новый код без новых миграций точно не заработает
или наоборот
SP
А как быть с БД? Если там есть неоткатываемые изменения? Типа drop column?
я сча серьезно - можно накапливать подобные изменения и после того как код уже точно не использует эти штуки дропать из схемы
КГ
или наоборот
всмысле?
AD
всмысле?
код может работать и без миграции
КГ
код может работать и без миграции
Новый?
AD
Новый?
+
КГ
Если у меня в новом коде новые сущности, как он без миграций будет работать?
VS
я сча серьезно - можно накапливать подобные изменения и после того как код уже точно не использует эти штуки дропать из схемы
Ну да, сейчас так и делаем. Не дропаем как минимум ещё 3 релиза
AM
Аккуратнее быть.
Вообще должен быть регрессный тест, который тестирует что старый код способен работать с новыми миграциями.
Как минимум потому что у тебя миграции и запуск кода не происходят одновременно и желательно сначала накатить миграции, и только потом спокойной запустить новый код.
Ибо новый код без новых миграций точно не заработает
Вообще должен быть регрессный тест, который тестирует что старый код способен работать с новыми миграциями.
Как минимум потому что у тебя миграции и запуск кода не происходят одновременно и желательно сначала накатить миграции, и только потом спокойной запустить новый код.
Ибо новый код без новых миграций точно не заработает
при этом тестить надо "по одной миграции", да?
AM
а не сразу после пачки
AD
Если у меня в новом коде новые сущности, как он без миграций будет работать?
я думал мы про обновление чего-то, что уже используется
КГ
при этом тестить надо "по одной миграции", да?
почему?
AM
почему?
потому что миграции не проходят в одной транзакции и код может работать с промежуточным (между миграциями) состоянием