Комментарии 10
Очень сложно с БД, как мне кажется. Мы у себя обратно-несовместимые изменения схем выполняем в несколько этапов.
Почему обновление фронтов такое многомудрое? Почему нельзя выкинуть веб-сервер из ротации на балансировщике, спокойно его обновить-прогреть и вернуть обратно в балансировщик?
Почему такие строгие требования к "версионности" сервисов? Почему не разрешить версии сервиса M.N, ранее работавшей с сервисом версии P.K, общаться с версией сервиса P.K+1?
Клиенты пишут-читают свои и общие данные. Теоретически, несмотря на «липкость», делают это на разных фронтах.При выводе из балансировщика — наверняка на разных фронтах. Формат данных при обновлении поменялся. Что делать?
Поддерживать в коде цепочку конвертеров между соседними версиями ну очень сильно не хотелось. Хотя такой вариант даже разрабатывали.
В итоге, один раз конвертируем всё и больше не паримся.
Версии идут не строго +1. Там есть своя «система» :) И опять же форматы обмена тоже могут быть не совместимы.
Поддерживать в коде цепочку конвертеров между соседними версиями ну очень сильно не хотелось. Хотя такой вариант даже разрабатывали.
В итоге, один раз конвертируем всё и больше не паримся.
Версии идут не строго +1. Там есть своя «система» :) И опять же форматы обмена тоже могут быть не совместимы.
Извините за оффтоп, но картинки — шик :)
Лишь малая часть знаний задокументирована в вики или ютреке, большая же — сокрыта в исходниках системы контроля версий. Премудрых старцев, умеющих расшифровать этот тайный код, в проекте всё меньше и меньше.
Вот это меня несколько взволновало. Скажите, сколько разработчиков у вас в команде сейчас разбираются в этой кастомной системе деплоя? Не на уровне пользователя, а на уровне способности допилить что-то или разобраться в нетривиальном баге. Как вы гарантируете преемственность этих знаний? Наверняка рано или поздно разработчики системы деплоя покинут проект, и их будет сложно достать.
Без паники, Алексей. В команде уже несколько человек допиливали код Деплоя или, например, прикручивали к нему веб-морду. При должном усердии прочитать код на C# получится у большинства.Просто пока «старцы» рядом, проще спросить. Чаще всего вопросы именно про механику или инженерные решения, после осознания ответов уже становится всё просто.
Немного не вкурил про то, как отрабатывается запрос со старого клиента к новому приложению.
То есть у меня загружены все скрипты, актуальные на старых данных/API — сервис обновился — я решил что-то сделать и запрос отправился, но API уже новый.
Приходит 400 Bad request и скрипт обновляет страницу для получения актуального клиента в браузере?
То есть у меня загружены все скрипты, актуальные на старых данных/API — сервис обновился — я решил что-то сделать и запрос отправился, но API уже новый.
Приходит 400 Bad request и скрипт обновляет страницу для получения актуального клиента в браузере?
Когда обновляется API, конечно, нужна перезагрузка. Клиент с тем же успехом мог просто открыть страницу месяц назад, а потом кнопку нажать. Или невалидный json отправить.Для таких случаев ничего специально не делали, refresh обычно помогает.
но вы его не форсите, так?
т.е. пользователь жмет кнопку, она не срабатывает (отмер endpoint, невалиден json или что-то другое), он бесится, жмет перезагрузку, так?
просто конкретизирую, тк думаю, стоит ли это применять у себя или забить
можно было бы возвращать определенный подходящий http-код и при обработке response на уровне всего приложения, в случае получения данного кода, делать page refresh
т.е. пользователь жмет кнопку, она не срабатывает (отмер endpoint, невалиден json или что-то другое), он бесится, жмет перезагрузку, так?
просто конкретизирую, тк думаю, стоит ли это применять у себя или забить
можно было бы возвращать определенный подходящий http-код и при обработке response на уровне всего приложения, в случае получения данного кода, делать page refresh
В принципе, в приложении есть места, где пользователя автоматом редиректит, когда он делает что-то не то. Не хватает прав — иди на авторизацию, поменял реквизиты в середине визарда — иди на первый шаг, указал неверный id сущности — иди на «объект не существует», исключение вылетело — иди на страницу ошибки. Специально отличать ситуации, когда api меняется от версии к версии и форсить редиректы мы не стали, да и довольно сложно вычленить именно такие случаи от всех остальных. Если страница переехала, мы пишем редиректы, а если json поменялся, ну мало ли, где он его взял, то ли браузер кривой, то ли postman криво использует.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Песнь о могучем Деплое: безостановочное прозрачное развёртывание веб-сервиса