Mon installation Discourse est obsolète (3.2.0.beta4-dev) et je dois passer à la version 3.5. Je crains de perturber les choses et j’utilise quelques plugins/intégrations que je n’ai pas voulu modifier (WP Discourse, connexion via Wordpress avec informations d’adhésion et plugin Category Lockdown) et j’ai déjà eu des problèmes lors de mises à niveau manuelles par le passé.
Quelle est la meilleure approche pour effectuer la mise à niveau ? Devrais-je faire une sorte de mise à niveau partielle vers une autre version d’abord ? Y a-t-il des pièges dont je devrais être conscient ?
Il y a de fortes chances que vous puissiez simplement suivre la mise à niveau PG 15 et que tout ira bien, mais vous avez posé la question sur les « meilleures pratiques ».
Cela a quelques bons effets secondaires, comme s’assurer que vous avez une sauvegarde récente et que vous avez une copie sûre de cette sauvegarde. Vous devez faire ces choses, quelle que soit la manière dont vous abordez votre mise à niveau.
J’ai l’impression qu’il serait une bonne pratique de commenter tous vos plugins également, mais il serait bon que quelqu’un confirme cela.
Ouais. En fait, savoir que vous pouvez démarrer un nouveau serveur et restaurer une sauvegarde. J’ai dû le faire une fois récemment lorsqu’un des SSD de mon serveur est tombé en panne. J’aurais aimé avoir pratiqué (bien que, comme il s’est avéré, même si je n’avais pas explicitement pratiqué, être passé par le processus des centaines de fois était suffisant et tout s’est déroulé comme prévu).
Il n’y a aucun inconvénient, d’autant plus qu’un tas de plugins ont été intégrés au cœur et qu’il pourrait y avoir quelque chose d’ancien qui est cassé. Une fois que tout fonctionne, vous pouvez alors restaurer les plugins que vous remarquez manquants.
Meilleure pratique ? Gardez une liste de contrôle quelque part, vous pouvez en ajouter une dans l’interface utilisateur admin > update en ajoutant ce CSS à votre thème (../admin/customize/themes/ edit) si un jour vous ou quelqu’un d’autre avez l’idée de mettre à jour trop rapidement :
.admin-contents.update .d-nav-submenu::before {content:“Liste de contrôle de mise à jour” : Sauvegarde effectuée ?\" ; « Dernières annonces méta du mois lues ? ; derniers bugs importants du mois de Meta vérifiés ? Compatibilité des plugins essentiels vérifiée ? Version de compatibilité Postgres/Redis vérifiée ? Bon timing pour la mise à jour vérifié ? Disponibilité de la main-d'œuvre de dépannage en cas d'échec de la mise à jour vérifiée ? }
Les listes de contrôle sont une bonne idée. Pour ma part, envisageant une mise à niveau, j’attends une publication, j’attends quelques jours, j’attends un jour de semaine, je lis les catégories Bugs et Support pour voir quels problèmes les gens rencontrent. Et j’attends que ces problèmes, le cas échéant, soient résolus.
Non, je suis sur tests-passed. Il est vrai que mon délai de quelques jours permettra à d’autres commits de s’ajouter au dépôt, mais en même temps, cela permettra de corriger certaines erreurs. Presque tous les commits, bien sûr, ne sont pas problématiques, donc je pense que c’est un bon compromis, mais les opinions peuvent différer.
Il y a une vague de mises à niveau juste après une nouvelle bêta, donc même sur les tests réussis, quelques jours après une mise à niveau est un bon moment pour une mise à niveau. Ou, peut-être partageons-nous la même logique erronée !
Je pense que vous verriez, euh, quelque chose comme le pourcentage de commits liés aux bugs (je ne suis pas sûr de la façon de quantifier cela - peut-être simplement compter ceux qui contiennent « FIX » dans le commit ?) pour les 5 jours suivant une version par rapport au pourcentage pour le reste du temps.
