Как безопасно обновить живой сайт - PullRequest
7 голосов
/ 10 марта 2009

У нас есть довольно простой веб-сайт на основе Django для выполнения операций CRUD. Я проводил тестирование и разработку локально, а затем проверял релизы и изменения схемы базы данных на работающем сервере после завершения тестирования. Недавно мы столкнулись с проблемой при выпуске некоторых типов изменений. Представьте себе следующую последовательность событий:

  1. Пользователь открывает веб-форму
  2. Сайт обновлен и требует нового поля в этой форме
  3. Пользователь отправляет форму, над которой он работал
  4. Сервер возвращает ошибку, потому что ожидал получить новое поле, добавленное на шаге 2

Как другие сайты решают такие проблемы? Мои идеи:

  • Переведите сайт в автономный режим во время обновления. Это на самом деле не решает проблему, потому что пользователь может открыть веб-форму на неограниченное количество времени до ее отправки, но после определенное количество времени вряд ли кто-либо будет отправлять форму.
  • Выполняйте автоматические обновления при очень низком времени трафика. Опять же, это не решает проблему, но наш сайт не так популярен, и если мы сделаем обновление в 3:00, я сомневаюсь, что быть много пользователей. Одной из проблем, связанных с этой техникой, являются автоматические обновления, которые дают сбой.
  • Версионные формы , чтобы сервер распознал отправку старой формы и предоставил более удобный для пользователя ответ. Есть ли автоматизированные инструменты, которые могут помочь с этим?

Мысли

Ответы [ 5 ]

2 голосов
/ 10 марта 2009

Изменения в опубликованном API (или в этом случае в пользовательском интерфейсе) всегда непростые. Если возможно, сохраните обратную совместимость. Я полагаю, что для большинства форм функциональность не меняется между версиями. Вы можете добавить или удалить поле или два, но это будет обработано проверкой формы на сервере. По сути, это то, что вы описываете в своем шаге 4. На самом деле я не считаю, что это большая проблема; Ошибки во время выполнения случаются время от времени - если ваше приложение корректно обрабатывает его и информирует пользователя о проблеме, то на самом деле проблем нет.

1 голос
/ 10 марта 2009

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

0 голосов
/ 10 марта 2009

«Правильный» способ сделать это - иметь четко определенные представления, которые корректно обрабатывают весь этот класс ошибок. В случае добавления нового поля в вашу модель, которое требуется (я предполагаю, что это то, что происходит), представление должно иметь дело с этим с исключением ValidationError, которое выдает дружественное сообщение об ошибке и отправляет пользователя обратно в форму (которая после перезагрузки должно быть доступно новое поле). Независимо от того, какие поля добавлены в модель, исключение выдаст чистую ошибку и отправит пользователя обратно.

0 голосов
/ 10 марта 2009

Я пользуюсь многими сайтами (предоставленными, в основном внутренними для моего места работы), на которых объявляется что-то вроде: «Мы будем на техническом обслуживании в ближайшие выходные с 18:00 субботы до 6:00 утра воскресенья. Пожалуйста, планируйте отключить систему в это время. " Хотя он не идеален, ничего нет, и это кажется хорошим подходом. Просто выделите достаточно времени, чтобы потушить новый материал, протестируйте его и откатитесь на старый, если это необходимо. Если вы чувствуете, что это необходимо, вы всегда можете создать простую страницу с надписью «Извините, мы не доступны сейчас» и направлять людей к этому в течение простоя. Как правило, никто не будет жаловаться, если вам не нужно все время, которое вы первоначально заявили, и вы вернулись рано (возможно, бездельники, которые хотят оправдаться, чтобы избежать работы, были бы исключением, но они, вероятно, тогда не работают).

0 голосов
/ 10 марта 2009

Я не могу понять, как вы могли бы достичь этого, не указав в проверке возможность обновления. например. «ожидание», что поля могли измениться при отправке, и либо установка значений по умолчанию / отклонение соответственно.

А как насчет «сокращения» представления контента по мере приближения окна обслуживания, чтобы минимизировать влияние пользователей на тех, кто оставил свои браузеры открытыми?

...