La mia installazione di Discourse è diventata obsoleta (3.2.0.beta4-dev) e devo aggiornarla alla 3.5. Sono preoccupato di poter compromettere le cose e utilizzo alcuni plugin/integrazioni che non ho voluto modificare (WP Discourse, login tramite Wordpress con informazioni sull’iscrizione e il plugin Category Lockdown) e in passato ho avuto problemi con gli aggiornamenti manuali.
Qual è il miglior approccio per eseguire l’aggiornamento? Dovrei fare una sorta di aggiornamento parziale a una versione diversa prima? Ci sono delle insidie di cui dovrei essere a conoscenza?
Questo ha alcuni buoni effetti collaterali, come assicurarsi di avere un backup recente e una copia sicura di tale backup. Devi fare queste cose, tuttavia tu approcci il tuo aggiornamento.
Ho l’impressione che sarebbe una buona pratica commentare anche tutti i tuoi plugin, ma sarebbe bene che qualcuno lo confermasse.
Sì. In effetti, sapere che puoi avviare un nuovo server e ripristinare un backup. Ho dovuto farlo una volta di recente quando uno dei miei server ha avuto un SSD guasto. Avrei voluto averlo effettivamente praticato (anche se, a quanto pare, anche se non avevo praticato esplicitamente, essere passato attraverso il processo centinaia di volte è stato sufficiente e tutto è andato come previsto).
Non c’è alcuno svantaggio, specialmente da quando un sacco di plugin sono stati spostati nel core e potrebbe esserci qualcosa di vecchio che è rotto. Dopo che la cosa è in ordine, puoi procedere a ripristinare tutti i plugin che noti mancanti.
Migliore pratica? Tieni una checklist da qualche parte, puoi aggiungerne una nell’UI admin > update aggiungendo questo CSS al tuo tema (../admin/customize/themes/ edit) se un giorno tu o qualcun altro aveste l’idea di aggiornare troppo velocemente:
.admin-contents.update .d-nav-submenu::before {content:“Checklist di aggiornamento” : Backup effettuato? " ; "Annuncio meta del mese scorso letto? Controllati i bug più importanti del meta del mese scorso? Verificata la compatibilità dei plugin essenziali? Verificata la versione di compatibilità Postgres/Redis? Verificato il momento giusto per l'aggiornamento? Disponibilità della forza lavoro per la risoluzione dei problemi in caso di fallimento dell'aggiornamento? }
Le checklist sono una buona idea. Per quanto mi riguarda, pensando a un aggiornamento, aspetto una release, aspetto un paio di giorni, aspetto un giorno feriale, leggo le categorie Bug e Supporto per vedere quali problemi le persone stanno riscontrando. E aspetto che quei problemi, se ce ne sono, vengano risolti.
No, sono su tests-passed. È vero che il mio ritardo di qualche giorno permetterà l’aggiunta di altri commit al repository, ma allo stesso tempo permetterà la correzione di alcuni errori. Quasi tutti i commit, ovviamente, non sono problematici, quindi penso che sia un buon compromesso, ma le opinioni possono differire.
C’è un’ondata di aggiornamenti subito dopo una nuova beta, quindi anche sui test superati, qualche giorno dopo un aggiornamento è un buon momento per un aggiornamento. O, forse condividiamo la stessa logica difettosa!
Penso che, uh, vedresti qualcosa come la percentuale di commit correlati a bug (non sono sicuro di come quantificarlo, forse contare quelli con “FIX” nel commit?) per i 5 giorni successivi a una release rispetto alla percentuale per il resto del tempo.
