Mi instalación de Discourse se ha quedado obsoleta (3.2.0.beta4-dev) y necesito actualizarla a la versión 3.5. Me preocupa estropear cosas y utilizo algunos complementos/integraciones que no he querido cambiar (WP Discourse, inicio de sesión a través de Wordpress con información de membresía y el complemento Category Lockdown) y he tenido problemas al actualizar manualmente en el pasado.
¿Cuál es el mejor enfoque para realizar la actualización? ¿Debería hacer algún tipo de actualización parcial a una versión diferente primero? ¿Hay algún problema que deba tener en cuenta?
Esto tiene algunos buenos efectos secundarios, como asegurar que tienes una copia de seguridad reciente y una copia segura de esa copia de seguridad. Necesitas hacer esas cosas, sin importar cómo abordes tu actualización.
Tengo la impresión de que sería una buena práctica comentar también todos tus plugins, pero sería bueno que alguien lo confirmara.
Sí. De hecho, saber que puedes iniciar un nuevo servidor y restaurar una copia de seguridad. Tuve que hacer esto una vez recientemente cuando uno de mis servidores tuvo un SSD que falló. Deseé haber practicado realmente (aunque, resultó, aunque no había practicado explícitamente, haber pasado por el proceso cientos de veces fue suficiente y todo salió según lo planeado).
No hay inconveniente, especialmente porque un montón de plugins se movieron al núcleo y podría haber algo antiguo que esté roto. Después de que el sistema funcione correctamente, puedes restaurar los plugins que notes que faltan.
¿Mejor práctica? Guarda una lista de verificación en algún lugar, puedes agregar una en la interfaz de usuario de admin > update agregando este CSS a tu tema (../admin/customize/themes/edit.css) si algún día tú o alguien tiene la idea de actualizar demasiado rápido:
.admin-contents.update .d-nav-submenu::before {content:“Lista de verificación de actualización” : ¿Copia de seguridad realizada?\" ; ¿Anuncio meta del mes pasado leído? ; ¿Comprobados los errores más importantes de meta de los últimos meses? ¿Comprobada la compatibilidad de plugins esenciales? ¿Comprobada la versión de compatibilidad de Postgres/Redis? ¿Momento adecuado para la actualización comprobado? ¿Disponibilidad de la fuerza de trabajo para la resolución de problemas en caso de fallo de la actualización comprobada? }
Las listas de verificación son una buena idea. Por mi parte, al contemplar una actualización, espero a una versión, espero un par de días, espero a un día de semana, leo las categorías de Errores y Soporte para ver qué problemas tiene la gente. Y espero a que esos problemas, si los hay, se solucionen.
No, estoy en tests-passed. Es cierto que mi retraso de unos días permitirá que se añadan más commits dispersos al repositorio, pero al mismo tiempo permitirá que se corrijan algunos errores. Casi todos los commits, por supuesto, no son problemáticos, así que creo que es un buen compromiso, pero las opiniones pueden diferir.
Hay una avalancha de actualizaciones justo después de una nueva beta, por lo que incluso en pruebas superadas, unos días después de una actualización es un buen momento para actualizar. ¡O, quizás compartimos la misma lógica defectuosa!
Creo que, eh, verías algo como el porcentaje de confirmaciones relacionadas con errores (no estoy seguro de cómo cuantificar eso, ¿quizás contar solo aquellas con “FIX” en la confirmación?) durante los 5 días posteriores a una versión en comparación con el porcentaje durante el resto del tiempo.
