Come rimuovere correttamente un modulo in un ambiente a fasi?

Alcuni moduli hanno routine di deinstallazione. Che di solito rimuovono i database disponibili per quel modulo, le variabili dalla tabella delle variabili e le localizzazioni introdotte da quel modulo. Queste routine vivono nel .installdi quel modulo.

Pertanto, non possono essere eseguiti senza che quel modulo sia presente. Quindi ecco i nostri passi attuali. La mia domanda è: può essere fatto in modo più semplice ed efficace? Di 'che rimuovo il modulo foo_bar.

1. In RCS, preparare una nuova versione, in cui:
   • Tutti i CSS e le sostituzioni di temi che usano o si basano su of foo_bar vengono rimossi.
   • Tutti i CSS e le sostituzioni di temi per i moduli a seconda di foo_bar vengono rimossi.
2. Spingi quel rilascio all'accettazione. Testare la disattivazione (da admin / moduli) con una copia molto recente del database di produzione.
3. Se tutto va bene, distribuisci il nuovo codebase alla produzione e deinstall foo_bar e le sue dipendenze lì. Questo invocherà la disinstallazione nei vari moduli, ripulendo il database.
4. In RCS (git), preparare una nuova versione in cui il codice viene effettivamente rimosso.
5. Distribuiscilo all'accettazione laddove testiamo se nulla dipendesse accidentalmente da questo (alcuni brutti moduli o funzioni tematiche includono file direttamente da altri moduli. In particolare CSS, JS o file immagine).
6. Se accettato, distribuire la nuova versione alla produzione. la produzione ora ha un database pulito e una base di codice pulita .

Il problema che non riesco a vedere come risolvere è che ciò richiede sempre due versioni. Poiché in Drupal una versione richiede che il sito sia offline, ciò significa due volte di inattività solo per rimuovere un modulo. Richiede anche due procedure di rilascio che, in ambienti di hosting professionale, possono essere molto costosi, che richiedono tempo o frustranti.

Se rimuoviamo il modulo da codebase nella prima iterazione, non possiamo eseguire i hook di disinstallazione, mantenendo molti lanugine nel database; non solo alcune tabelle, ma principalmente variabili e impostazioni locali. Se non rimuoviamo il modulo da codebase, ciò significa che codebase crescerà con codice non aggiornato e non utilizzato; ciò non comporta alcun sovraccarico di prestazioni, ma rende il mantenimento del codice sempre più difficile.

come lo gestisci?

[modifica: aggiunta nota sul fatto che la distribuzione è una procedura difficile, spesso]

Prestare molta attenzione a mantenere sincronizzati il ​​database e il codice; come menzionato nella domanda, i moduli da disinstallare devono rimanere nella base di codice fino a quando i loro hook di disinstallazione non vengono eseguiti sul database live. Questa è una limitazione di Drupal che un flusso di lavoro git pull da solo non risolverà.

Raccomanderei che invece di tentare di adattare il processo, cerchi invece modi per ridurre i tempi di inattività richiesti per elaborare gli aggiornamenti. Consiglierei di impostare un ambiente di stadiazione multisito ying / yang per risolvere questo problema. nb non ho usato gli script contenuti nel link precedente; potresti voler impostare le cose in modo diverso, seguendo la stessa idea che puoi scambiare i tuoi siti live e sul palco durante la distribuzione.

Continuare a seguire la stessa procedura descritta nella domanda con le seguenti modifiche:

un. Sincronizzazione da dev a stage (yang) come al solito. Prova eseguendo una disinstallazione dei moduli da rimuovere seguita dalla rimozione del codice, ecc. Note sul flusso di lavoro Git: crea un tag o nota l'hashid dei diversi stati del tuo codice: tutti i moduli in atto prima della disinstallazione, moduli di codice rimossi, il tuo sostituisce & c. rimosso, ecc. secondo necessità. Forse sono necessari solo due riferimenti.

b. Quando il test è completo e accettato, ripristina il codice sul palco (yang) allo stato live (ying).

c. Preparare il sito live (ying) per l'aggiornamento disabilitando la possibilità di qualsiasi utente di modificare il contenuto del sistema. Un aggiornamento sql alla tabella dei permessi di solito farà qui. A questo punto, gli utenti saranno ancora in grado di leggere il contenuto sul sito live, ma riceveranno un errore di autorizzazione negata se provano ad aggiornare il contenuto. (Se sei forte, forse potresti modificare il permesso negato al gestore per stampare un avviso appropriato che la funzione è temporaneamente non disponibile).

d. Ora riporta il database live (ying) al database stage (yang), escludendo la tabella delle autorizzazioni dall'aggiornamento.

e. Ripetere il passaggio a. ancora. Se hai gli hashtag a portata di mano, dovrebbe essere facile ripristinare lo stato in cui esistono i moduli da rimuovere, eseguire gli hook di disinstallazione sul database e quindi tornare allo stato del codice in cui vengono uniti i tuoi elementi dal passaggio 1 di nuovo dentro.

f. Ora sei pronto per scambiare ying e yang. Fallo modificando le direttive di configurazione di Apache. Si noti che se si esegue una /etc/init.d/apache restart, alcune connessioni potrebbero essere eliminate, ma /etc/init.d/apache reloadconsentirà uno scambio pulito.

g. Live è ora "yang"; la tabella delle autorizzazioni non è modificata qui, quindi gli utenti possono creare contenuti. Se automatizzi i passaggi e. e f., il tempo non disponibile dovrebbe essere molto basso.

h. Riporta live (yang) allo stage (ying), sia codice che database - oppure invia da dev, se necessario. Ora hai un ambiente pulito pronto per la tua prossima iterazione.