Per quanto riguarda l’aggiornamento del codice sorgente di Discourse, delle dipendenze a livello di sistema operativo, dell’immagine base Docker, dei gem Ruby e di elementi simili, è possibile procedere eseguendo la build in due fasi e svolgendo le attività sopra menzionate nella prima fase.
Questa prima fase è indipendente dall’ambiente e può essere eseguita anche in un ambiente CI (quindi si potrebbe utilizzare un’immagine quasi identica negli ambienti di staging e produzione, evitando possibili errori dovuti a ricostruzioni in date diverse, per non parlare della riduzione dei tempi di inattività).
Le attività di migrazione del database e di assets:precompile dovrebbero comunque essere eseguite sulla macchina di destinazione. Nella maggior parte dei casi, la migrazione del database sarebbe veloce. D’altra parte, il compito assets:precompile rappresenta un problema perché è la fase che richiede più tempo. Credo che ciò sia dovuto al fatto che alcune risorse devono conoscere alcune informazioni ambientali definite nel database, come alcune regole CSS, per essere eseguite.
Sarebbe estremamente positivo se questo compito fosse suddiviso in due parti: nella prima, tutte le risorse che non dipendono dall’ambiente verrebbero elaborate e potrebbero essere eseguite in un ambiente CI; nella seconda fase, verrebbero compilate solo le risorse che dipendono da dati presenti nel database, ecc. Detto questo, non so quanto sia tecnicamente complesso implementare questa soluzione.
Ho discusso dell’avvio del contenitore dell’applicazione in due fasi nel seguente argomento:
Le modifiche che ho apportato riguardavano esclusivamente la suddivisione del modello web di Discourse in tre file, ma i compiti restano gli stessi. Tuttavia, sarebbe ottimo se il team di Discourse supportasse questa modalità, in modo da non dover aggiornare i file ogni volta che ci saranno cambiamenti futuri nel modello web.