Comment mettre à jour en toute sécurité un site Web en direct

Question

Nous avons un site Web basé sur Django assez simple pour effectuer des opérations CRUD. J'ai fait du test et du développement en local, puis j'ai vérifié les versions et les changements de schémas de base de données sur le serveur live une fois que les tests sont terminés. Nous avons récemment rencontré un problème lors de la publication de certains types de modifications. Imaginez la séquence des événements suivants:

1. L'utilisateur ouvre un formulaire web
2. site est mis à jour pour exiger nouveau champ sur ce formulaire
3. utilisateur soumet le formulaire qu'ils ont travaillé sur
4. Server renvoie une erreur car il s'attendait à recevoir le nouveau champ qui a été ajouté à l'étape 2

Comment d'autres sites traitent-ils ces types de problèmes? Mes idées:

• Mettez le site hors ligne pendant les mises à jour. Cela ne résout pas vraiment le problème, car un utilisateur peut avoir un formulaire Web ouvert pendant une période de temps infinie avant de le soumettre, mais après un certain laps de temps, il est peu probable que quelqu'un soumette le formulaire.
• Faire des mises à jour automatiques à des temps de trafic très faibles. Encore une fois cela ne résout pas vraiment le problème, mais notre site n'est pas très populaire et si nous avons fait une mise à jour à 03h00, je doute qu'il y aurait beaucoup d'utilisateurs. Une préoccupation avec cette technique est les mises à jour automatiques qui échouent.
• La gestion des versions consiste à formater le formulaire afin que le serveur reconnaisse qu'un ancien formulaire est soumis et offre une réponse plus conviviale. Y a-t-il des outils automatisés qui pourraient aider à cela?

Pensées?

Answer 1

Je ne vois pas comment vous pourriez réaliser cela sans coder dans votre validation la possibilité d'une mise à jour. par exemple. "anticiper" que les champs peuvent avoir changé lors de la soumission et définir les valeurs par défaut/rejet en conséquence. Qu'en est-il de la "réduction" de la soumission de contenu à l'approche d'une fenêtre de maintenance, pour minimiser les utilisateurs impactés à ceux qui ont laissé leur navigateur ouvert?

Answer 2

Si c'est vraiment un gros problème, vous pouvez inclure la version de code comme une sorte de variable cachée dans chacun de vos formulaires. Si la version soumise ne correspond pas à la version en cours d'exécution de l'application, vous pouvez afficher une erreur correcte, et les amener à remplir tous les nouveaux champs qui pourraient exister sur le formulaire. Vous pouvez même aller un peu plus loin et n'afficher que les messages pour lesquels le formulaire a changé. Créer éventuellement une sorte de hachage basé sur la définition du formulaire, et l'utiliser comme champ caché. Si le hachage est incorrect, vous savez qu'ils soumettent un formulaire incorrect.

Answer 3

Les modifications apportées à une API publiée (ou à l'interface utilisateur, dans ce cas) sont toujours complexes. Si possible, conserver la compatibilité ascendante. Pour la plupart des formulaires, je reconnais que la fonctionnalité ne changerait pas entre les versions. Vous pouvez ajouter ou supprimer un champ ou deux, mais cela sera géré par la validation du formulaire sur le backend. C'est essentiellement ce que vous décrivez à l'étape 4. Je ne considère pas vraiment cela comme un problème; Les erreurs d'exécution se produisent d'un moment à l'autre - Tant que votre application le gère avec élégance et informe l'utilisateur du problème, alors aucun problème.

Answer 4

Il y a beaucoup de sites que j'utilise (accordés, la plupart du temps internes à mon lieu de travail) qui annoncent quelque chose comme "Nous serons en panne pour entretien ce week-end à partir de 18h00 samedi à 6h00. S'il vous plaît, prévoyez d'être hors du système à ce moment-là. " Bien que ce ne soit pas parfait, rien n'est, et cela semble être une bonne approche. Il suffit de découper suffisamment de temps pour éteindre les nouveaux éléments, les tester et revenir à l'ancien si nécessaire. Si vous pensez que c'est nécessaire, vous pouvez toujours créer une page simple qui dit «Désolé, nous ne sommes pas disponibles maintenant» et diriger les gens vers cela pendant le temps d'arrêt. Généralement personne ne se plaindra si vous n'avez pas besoin de tout le temps que vous avez indiqué et vous êtes de retour tôt (peut-être les fainéants qui veulent une excuse pour éviter le travail serait l'exception, mais ils ne fonctionnent probablement pas de toute façon).

Answer 5

La manière correcte de le faire est d'avoir des vues bien définies qui gèrent gracieusement toute cette classe d'échec. Dans le cas d'ajouter un nouveau champ à votre modèle qui est nécessaire (je présume que c'est ce qui se passe), la vue devrait traiter cela avec une exception ValidationError qui envoie un message d'erreur amical et renvoie l'utilisateur au formulaire (qui , quand rechargé, devrait avoir le nouveau champ disponible). Quels que soient les champs ajoutés au modèle, l'exception renvoie une erreur propre et renvoie l'utilisateur.