Qual è il flusso di lavoro suggerito per la migrazione della configurazione (CMI) dalla produzione dev -> stage ->?

41

Abbiamo avuto un drupalcamp qualche mese fa e qualcuno ha chiesto informazioni sulla gestione delle implementazioni con il nuovo sistema di configurazione (CMI). Un possibile flusso di lavoro ideale consisterebbe nel mantenere la configurazione nel controllo della versione e riuscire comunque a migrare la configurazione tra i membri del team.

Il meglio che siamo riusciti a capire nella sala (parzialmente basato sulla presentazione al DrupalCon Portland) è stato:

Di 'al controllo versione di ignorare la directory di configurazione attiva.
Copia tutta la configurazione nella directory di gestione temporanea e passa al controllo versione.

E usa settings.php per invertire la directory active / staging tra i 2 ambienti. Tuttavia, mentre capire un flusso di lavoro di distribuzione da un server all'altro era complesso ma fattibile, qual è il flusso di lavoro suggerito da più ambienti locali (cioè più sviluppatori) in sviluppo (o tra di loro) - Un possibile problema potrebbe essere ogni membro del team condividerebbe lo stesso o simile ambiente, quindi come si verificano i cambiamenti sulla macchina di un compagno di squadra?

migration 8 version-control

— btmash
fonte

5

Non sono davvero d'accordo con gli attuali voti stretti. Dato che CMI è al centro di Drupal 8, penso che possiamo avere delle buone risposte qui.

— mpdonadio

3

D'accordo, questa è un'ottima domanda. Credo che il compito critico drupal.org/node/1703168 riguardi questo e altri argomenti e non sia ancora stato completamente risolto, quindi una risposta qui potrebbe aiutare a portare avanti questo problema.

— Berdir,

Mi scuso se la mia domanda è risultata negativa nei confronti dell'iniziativa CMI (che non era affatto mia intenzione). Ho aggiornato la domanda in modo che sembri più neutrale.

— btmash,

2

stavo quasi per dire "Hai provato le funzionalità". Forse la "D8" dovrebbe andare nel titolo della domanda? Il tag "8" è un po 'invisibile.

— donquixote,

1

Ho rivisto il titolo in modo che la domanda sia visibile sia per tag sia per titolo :)

— btmash,

19

Dopo aver parlato un po 'con i manutentori del CMI, la discussione su quale sia l'approccio migliore non è finita, ma il seguente è ciò che ha più senso al momento.

Cercando di mantenerlo per ora, proverò ad espandersi in base alle domande / quando il problema a cui viene fatto riferimento viene risolto con una risposta ufficiale.

Quindi, prima di tutto, i fatti ...

Come già accennato, c'è la directory attiva e di gestione temporanea. Attivo è completamente gestito da Drupal, non è supportato apportare modifiche direttamente lì (dirette o indirette passando a una posizione diversa).
La gestione temporanea è il punto in cui Drupal cerca la configurazione da importare e altrimenti non se ne preoccupa.
Il processo di importazione è importante, le modifiche alla configurazione possono influire su un sito in un certo modo e devono essere verificate per la validità. Non è possibile modificare il tipo di campo di un campo di testo in un riferimento di entità, ad esempio che non funziona.
L'importazione della configurazione deve sempre essere eseguita su tutta la configurazione, non è possibile importare una singola vista o tipo di nodo. È stato provato, ma provare a far fronte alle dipendenze, a rimuovere / rinominare e così via ha prodotto un sistema molto complicato e non ha funzionato.
L'unico modo per reinstallare la configurazione predefinita è reinstallare quel modulo. Ciò significa che tenterebbe innanzitutto di rimuovere tutta la configurazione (come i campi). Quindi questa non è davvero un'opzione. Penso che siano possibili modifiche manuali e specifiche delle funzioni di aggiornamento, ma troppo noiose per questo.
Come descritto dal modulo caratteristiche, si concentrerà sulla fornitura di funzionalità riutilizzabili, non su continue implementazioni di configurazione. Questo è ciò per cui è stato progettato in primo luogo.

Detto questo, la raccomandazione in questo momento è quella di mettere la directory di gestione temporanea nel controllo della versione. Ogni sviluppatore ha quindi il pieno controllo su ciò che mette lì, copiando l'intera directory attiva o solo un file di configurazione specifico. Le modifiche alla directory di gestione temporanea vengono quindi sottoposte a commit, inviate alla produzione e viene eseguita l'importazione della configurazione (nell'interfaccia utente o con drush).

— Berdir
fonte

La directory di gestione temporanea nel controllo versione, ottengo quella parte. Le altre parti sono ciò che la mia mente sta tentando di elaborare. Quindi, se qualcuno apporta una modifica, copia le modifiche nella directory di gestione temporanea e la commette. Successivamente, gli altri sviluppatori / server successivo ottengono le modifiche e sincronizzano le modifiche nella directory attiva. E risciacqua e ripeti per qualsiasi altra catena di server lungo il percorso (stadiazione, produzione, ecc.). E passa sempre attraverso la gestione temporanea, quindi non si verificano più cambi di directory. Sarebbe accurato?

— btmash,

Sì. Non ci deve essere alcun cambio di directory. Ogni modifica alla configurazione deve passare attraverso il processo di importazione o potresti finire con un sito danneggiato. Ad esempio, l'elenco dei moduli è anche configurazione. La distribuzione implica che i moduli devono essere installati / disinstallati (Nota: non funziona ancora, ma c'è un problema per risolverlo).

— Berdir,

Ok, quindi ancora più domande ora (suddivise in 2 commenti) :) Innanzitutto, menzioni i moduli sono di configurazione. Quindi, anche se un modulo viene aggiunto a un repository e non abilitato / disabilitato, deve essere installato / disinstallato per essere semplicemente seduto lì?

— btmash,

E il seguente: (A) Ci sarà un meccanismo per copiare le modifiche dalla directory attiva -> staging (per semplificare rispetto a una persona che va nella directory di configurazione per questi componenti - possibilmente un modo per selezionare alcune variabili). (B) La directory di gestione temporanea viene svuotata dopo che le modifiche sono state sincronizzate dalla gestione temporanea -> attiva? (B1) In tal caso, allora la strategia è dal punto di vista devops di ripristinare quella directory prima di un git pull? (B2) In caso contrario, è corretto supporre che durante la messa in scena-> sincronizzazione attiva, non ci dovrebbe essere alcun effetto sulla configurazione che non è cambiato?

— btmash,

Lo stato di installazione del modulo è configurazione. Non il modulo stesso :) Questo è ciò che distribuisci. a) Esiste un'interfaccia utente per scaricare un tar.gz della directory attiva, uno per caricare detto tar.gz nella directory di gestione temporanea e uno per eseguire effettivamente l'importazione, con panoramica e differenze delle modifiche. B) Credo che ora sia svuotato, ma presumo che tu possa facilmente ripristinarlo con Git. Non sono sicuro, facile da controllare. Tutta quella roba è collegabile, quindi potrebbe esserci un'implementazione leggermente diversa che non cancella. B2) Non capisco questo, ma penso di si.

— Berdir,

4

Grande risposta finora. Grazie a tutti voi!

Di recente abbiamo avviato un progetto Drupal 8 e implementato il seguente flusso di lavoro.

Abbiamo tre cartelle attive, con gestione temporanea ed esportazione. Gli sviluppatori scaricano la loro esportazione. Non voglio tenerlo in scena. Penso che sia più facile lavorare con la configurazione condivisa non archiviata direttamente nella cartella di gestione temporanea. È solo un abbattimento, non ho fatti concreti su questo ...

Il nostro attuale modello di progetto drupal 8 è disponibile su github. Ho anche scritto alcuni comodi comandi di trascinamento per accelerare il devleoper worflow. Nessuna copia manuale da attiva a esportazione richiesta.

Modello di progetto: https://github.com/webflo/d8-project-template
Comandi Drush aggiuntivi: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— Webflo
fonte

1

Finora, sono d'accordo con questo approccio. Ho aggiunto tutte le funzionalità dei collegamenti in questo post ai comandi config-export e config-import di Drush. Spero che altri si uniscano a me e @florian nell'esplorazione di questa soluzione a 3 directory.

— moshe weitzman,

Come sites/default/files/config_HASHgestisci la cartella di configurazione con un suffisso hash, ad esempio config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow È possibile sovrascrivere la posizione di queste cartelle. Cerca "Posizione dei file di configurazione del sito". in settings.php uso il seguente frammento. Questo significa che la configurazione è memorizzata al di fuori della directory principale di Drupals. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— webflo,

Grazie @webflo ho visto questo. Quale sarebbe il vantaggio di gestire separatamente una base di codice e una configurazione? Penso che questa separazione sia un po 'artificiale poiché sia il codice che la configurazione (in yaml) determinano il comportamento e dipendono l'uno dall'altro. In Drupal 7, la configurazione nel codice (o tracciabile da Git) è stata eseguita con il modulo Features creando un modulo per ogni particolare configurazione che doveva essere tracciata nel codice. In Drupal 8, ci sono le funzionalità 3.x che, a mio modo di vedere, fa lo stesso ma usa YAML per memorizzare la configurazione e i moduli generati non dipendono dal modulo caratteristiche.

— therobyouknow,

Penso che tu mi abbia frainteso, la directory di configurazione è ancora in git, ma il mio sito Drupal non è nella radice del repo git. Il sito è archiviato / web. Quindi / config e / web sono allo stesso livello.

— webflo,

2

Non l'ho ancora provato, ma il mio piano è quello di creare un modulo personalizzato che contenga file di configurazione "predefiniti" contenenti solo la configurazione a cui tengo. Credo che altri moduli possano contenere configurazioni che sovrascrivono altri moduli. (In caso contrario, ciò dovrebbe essere reso possibile).

Penso che devi lasciare la cartella di configurazione da sola. Ignoralo. Viene generato automaticamente all'installazione da tutti i file di configurazione dei singoli moduli. Il percorso è lungo e casuale. Se hai tenuto tutto ciò in un repository, avresti bisogno di un repository separato e porteresti con sé tonnellate di file di configurazione predefiniti e non necessari.

Mettere la configurazione in un modulo personalizzato lo rende parte della tua base di codice principale.

Il processo di distribuzione sarebbe:

Git pull o altro per ottenere nuovi file.
Cancella cache.
Ripristina la configurazione predefinita. (Dai file del tuo modulo personalizzato)

È possibile creare moduli personalizzati (con la propria configurazione) per ogni ambiente, se lo si desidera.

— jonpugh
fonte

Questo suona molto come funzionalità, no? O c'è una differenza significativa che mi manca?

— Letharion,

È un approccio interessante e mi piace l'idea. Tuttavia, uno dei maggiori vantaggi menzionati nell'ambito dell'iniziativa CMI è la possibilità di spostarsi dalla configurazione alle directory di configurazione. E da quello che vedo, il file settings.php ti consente di dettare dove sono le directory attive / di gestione temporanea (cioè non devono essere percorsi generati automaticamente). Quindi, penso che un flusso di lavoro con l'attuale configurazione dovrebbe essere possibile senza la necessità di creare una funzionalità come menzionato sopra @Letharion.

— btmash,

2

Nota: apprezzo che questa non sia una risposta nel senso più stretto in relazione alla domanda, ma l'ho messa qui comunque e rivisiterò e modificherò / eliminerò una volta che Features ha una versione 8.x e la polvere ha risolto un po 'di più. Questo era troppo grande per un commento e volevo ottenere i miei £ 0,02 in :-)

Come grande fan di Features , suggerirei di tenere d'occhio l' incarnazione D8 del modulo Features .

Tratto dalla pagina del progetto

La versione 3.x delle funzionalità è prevista per Drupal 8 da integrare con il nuovo sistema di gestione della configurazione. Se hai semplicemente bisogno di esportare una semplice configurazione del sito, al posto delle Caratteristiche dovrebbe essere usato il sistema di gestione della configurazione D8. Utilizzerai le funzionalità in D8 per esportare le funzionalità in bundle (come una "funzione galleria fotografica").

Il modo in cui ho un po di vedere è che questa idea rende più facile per dev team di lavorare su parti più piccole di un sito. Non ho ancora intenzione di entrare in un flusso di lavoro, anche se ci sono ancora troppe variabili sconosciute, ma non riesco a vederlo così diverso da una procedura di distribuzione delle funzionalità corrente.

Non posso fare a meno di pensare di sì, CMI è fantastico; ma la maggior parte dei miei siti finirà comunque con i moduli Features (anche se una quantità inferiore a causa della non esportazione di OGNI tipo di contenuto, autorizzazione ecc.)

— Chapabu
fonte

Mentre sono d'accordo sul fatto che le funzionalità cambieranno leggermente il suo ruolo e (si spera) saranno lo strumento per raggruppare i componenti di configurazione insieme (come la funzionalità della galleria fotografica che menzioni), la configurazione (per quanto ho capito) continuerà a essere mantenuta tramite l'attivo directory di configurazione. Quindi le funzionalità possono risolvere un determinato componente, ma il vero problema è il modo in cui il flusso di lavoro della directory di configurazione viene gestito in tutti gli ambienti. La procedura di distribuzione è leggermente diversa dalla procedura di distribuzione delle funzionalità correnti principalmente poiché i dati di activestore sono nel db e il datastore è file.

— btmash,

... la procedura di distribuzione delle caratteristiche del d7 comporta l'attivazione dei dati nel database e nel deposito dati nei file. Ci stiamo spostando su entrambi i file e dobbiamo solo assicurarci in che modo influisce su un cambiamento nel flusso di lavoro.

— btmash,

Si noti che le funzionalità in realtà non hanno il concetto di active e datastore / staging. O almeno non coerente, tutto dipende dallo specifico hook / cosa con cui si sta integrando. Le viste predefinite vivono nel codice, ad esempio le modifiche sono immediatamente attive (a parte la memorizzazione nella cache), non esiste un processo di distribuzione controllato con funzionalità. Questo è sempre stato uno dei problemi principali quando si utilizzano le funzionalità per le distribuzioni.

— Berdir,

Hai ragione. Non so come ho fatto a confondere il modulo di configurazione per D7 con le caratteristiche, ma l'ho fatto.

— btmash,