Песнь о могучем Деплое: безостановочное прозрачное развёртывание веб-сервиса

[ostapbender]

Очень сложно с БД, как мне кажется. Мы у себя обратно-несовместимые изменения схем выполняем в несколько этапов.

Почему обновление фронтов такое многомудрое? Почему нельзя выкинуть веб-сервер из ротации на балансировщике, спокойно его обновить-прогреть и вернуть обратно в балансировщик?

Почему такие строгие требования к "версионности" сервисов? Почему не разрешить версии сервиса M.N, ранее работавшей с сервисом версии P.K, общаться с версией сервиса P.K+1?

[AlexTalapin]

Клиенты пишут-читают свои и общие данные. Теоретически, несмотря на «липкость», делают это на разных фронтах.При выводе из балансировщика — наверняка на разных фронтах. Формат данных при обновлении поменялся. Что делать?
Поддерживать в коде цепочку конвертеров между соседними версиями ну очень сильно не хотелось. Хотя такой вариант даже разрабатывали.
В итоге, один раз конвертируем всё и больше не паримся.

Версии идут не строго +1. Там есть своя «система» :) И опять же форматы обмена тоже могут быть не совместимы.

[Boomburum]

Извините за оффтоп, но картинки — шик :)

[AlexTalapin]

Огромное спасибо Кате! Нашему дизайнеру.

[BeeVee]

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

Вот это меня несколько взволновало. Скажите, сколько разработчиков у вас в команде сейчас разбираются в этой кастомной системе деплоя? Не на уровне пользователя, а на уровне способности допилить что-то или разобраться в нетривиальном баге. Как вы гарантируете преемственность этих знаний? Наверняка рано или поздно разработчики системы деплоя покинут проект, и их будет сложно достать.

[AlexTalapin]

Без паники, Алексей. В команде уже несколько человек допиливали код Деплоя или, например, прикручивали к нему веб-морду. При должном усердии прочитать код на C# получится у большинства.Просто пока «старцы» рядом, проще спросить. Чаще всего вопросы именно про механику или инженерные решения, после осознания ответов уже становится всё просто.

[fireharp]

Немного не вкурил про то, как отрабатывается запрос со старого клиента к новому приложению.

То есть у меня загружены все скрипты, актуальные на старых данных/API — сервис обновился — я решил что-то сделать и запрос отправился, но API уже новый.

Приходит 400 Bad request и скрипт обновляет страницу для получения актуального клиента в браузере?

[AlexTalapin]

Когда обновляется API, конечно, нужна перезагрузка. Клиент с тем же успехом мог просто открыть страницу месяц назад, а потом кнопку нажать. Или невалидный json отправить.Для таких случаев ничего специально не делали, refresh обычно помогает.

[fireharp]

но вы его не форсите, так?

т.е. пользователь жмет кнопку, она не срабатывает (отмер endpoint, невалиден json или что-то другое), он бесится, жмет перезагрузку, так?

просто конкретизирую, тк думаю, стоит ли это применять у себя или забить
можно было бы возвращать определенный подходящий http-код и при обработке response на уровне всего приложения, в случае получения данного кода, делать page refresh

[AlexTalapin]

В принципе, в приложении есть места, где пользователя автоматом редиректит, когда он делает что-то не то. Не хватает прав — иди на авторизацию, поменял реквизиты в середине визарда — иди на первый шаг, указал неверный id сущности — иди на «объект не существует», исключение вылетело — иди на страницу ошибки. Специально отличать ситуации, когда api меняется от версии к версии и форсить редиректы мы не стали, да и довольно сложно вычленить именно такие случаи от всех остальных. Если страница переехала, мы пишем редиректы, а если json поменялся, ну мало ли, где он его взял, то ли браузер кривой, то ли postman криво использует.