Benvenuti nella terra di F mangures C onfiguration M anagement, alias FCM ! Non si tratta solo di funzionalità e non di Configuration Management (come introdotto in Drupal versione 8). Invece, si tratta di un caso speciale di S oftware C ONFIGURAZIONE M anagement , aka SCM . Soprattutto perché le caratteristiche possono essere considerate come un generatore di codice, mentre quel codice generato deve essere migrato attraverso più ambienti. Continua a leggere per maggiori dettagli.
1 - Pro e contro dell'utilizzo delle funzionalità
Vantaggi dell'uso delle funzionalità
- Automatizza l'implementazione delle modifiche applicate a un sito di sviluppo di Drupal in uno o più siti di destinazione (pre) di produzione Drupal (invece della distribuzione manuale).
- Facilita la condivisione (spedizione) dello sviluppo Drupal in corso tra gli sviluppatori Drupal / i costruttori di siti (ad es. Per rendere alcune View create da un esperto di view disponibili per un Themer Drupal che lavora in un altro sito di sviluppo per temi che visualizzano).
- Ottima integrazione sia con GIT che con Drush per la spedizione di una copia del codice generato da Features (sul sito di sviluppo) su siti di (pre) produzione target selezionati.
Svantaggi dell'uso delle funzionalità
- Evitare conflitti di funzionalità e / o gestire le dipendenze delle funzioni può essere impegnativo!
- Non è facile iniziare a utilizzare le funzionalità su un sito (di produzione) esistente.
- Installare / abilitare il modulo Funzionalità è facile (solo un modulo), ma imparare a usare correttamente le Funzionalità è una grande sfida.
2 - Tecniche per il packaging delle caratteristiche
Utilizzando le funzionalità spetta alla tua immaginazione come impacchettare (comporre) il contenuto di una funzione. Ecco alcune tecniche che possono essere utilizzate per questo.
Una singola super funzionalità
Questa è una tecnica di packaging piuttosto semplice: tutto è impacchettato insieme in un'unica funzione (alcuni lo chiamano la funzione "Dio" ...). Sembra facile, piuttosto avanti, ecc. Ma questa tecnica porta anche a "conflitti" (come spiegato di seguito) più o meno subito ...
Un buon esempio per questo sembra essere quando si crea una "distribuzione Drupal", in cui si presume che tutti gli utenti utilizzino lo stesso insieme di moduli, configurazione, ecc. Se tuttavia tale distribuzione è costituita da più funzionalità del sito Web (per non usare la parola "caratteristiche" ...), sembra più appropriato dividere tali funzioni in più funzioni, come spiegato di seguito.
Basato sulla funzionalità del sito Web
Questa tecnica di packaging crea una funzionalità separata per ciascuna funzionalità di un sito Web, come ad esempio:
- Caratteristica A = implementa una " * Galleria ".
- Caratteristica B = implementare un " * Blog ".
- Caratteristica C = implementare un " * Calendario eventi ".
Basato sulle sezioni amministrative di Drupal
Questa tecnica di packaging crea funzionalità separate per ciascuna delle sezioni (principali) di amministrazione di un sito Web Drupal utilizzato per creare il sito, come ad esempio:
- Tutti i moduli richiesti sono contenuti nella funzione A,
- Tutte le definizioni dei campi base sono contenute nella funzione B,
- Tutti i tipi di contenuto sono contenuti nella funzione C,
- Tutte le autorizzazioni sono contenute nella funzione D,
- Tutti i ruoli sono contenuti nella funzione E,
- Tutte le variabili sono contenute nella funzione F,
- Tutte le viste (personalizzate) sono contenute nella funzione G,
- Tutte le regole (personalizzate) sono contenute nella funzione H,
- Eccetera.
L'elenco sopra è praticamente illimitato: alla fine potresti persino pensarlo come 1 funzionalità per ogni opzione del menu di amministrazione di Drupal ... se vuoi andare così lontano.
IMO è anche l'approccio più raccomandato alle funzionalità del pacchetto.
3 - Ridurre la probabilità di conflitti in Caratteristiche e / o GIT
Non riutilizzare i campi
Parecchi conflitti sembrano essere causati dal riutilizzo dei campi tra più tipi di contenuto. Ad esempio, nel tipo di contenuto A è presente un campo con nome macchina field_somefield, che viene utilizzato anche come campo nel tipo di contenuto B con lo stesso nome macchina field_somefieldma che come altro tipo di campo e / o altre impostazioni di campo che sono diverse.
Non riutilizzando i campi tra i tipi di contenuto, si evita di eseguire questo problema. Dai un'occhiata a un'interessante convenzione di denominazione per il nome della macchina dei tuoi tipi e campi di contenuto, come mostrato nella tabella di Wrapping Information Architecture and Documentation , che fa parte degli articoli su " Modello di relatività per Drupal ". Per maggiori dettagli a riguardo fai riferimento alla mia risposta a " Come modellare il contenuto (tipi) da un punto di vista incentrato sul database? ".
Dividi le funzionalità a seconda di chi lavora su cosa
Se più persone lavorano su un singolo sito, la quantità di conflitti può essere ridotta organizzando (= creando elementi separati) in base a chi lavora su cosa. Un'illustrazione di questo potrebbe essere come in questo esempio:
- Le viste vanno nella funzione A,
- Le regole vanno nella funzione B,
- I grafici vanno nella funzione C,
- Qualsiasi cosa su Theming va nella caratteristica D,
4 - Ambienti Drupal consigliati
Tutto quanto sopra dovrebbe aiutare a facilitare in qualche modo l'uso delle funzionalità . Tuttavia, per garantire che le cose funzionino come previsto (progettato), è necessario disporre anche di un set appropriato di ambienti (siti Web Drupal logicamente correlati) per questi motivi fondamentalmente:
- unire le funzionalità fornite da più funzionalità.
- prevedere e risolvere i conflitti.
- test dell'utente finale di tutte le funzionalità unite che sono certificate per non avere conflitti.
Nel mondo ideale, questi siti Web Drupal logicamente correlati dovrebbero essere configurati e utilizzati, in questo modo:
- Sito di sviluppo personale : ogni sviluppatore di siti Web ha un sito di sviluppo separato. Quando una parte dello sviluppo è pronta per essere condivisa con qualcun altro, viene creata una funzionalità appropriata, che viene spedita nell'ambiente di gestione temporanea.
- Sito Sandbox : si tratta di un ambiente Drupal che contiene solo core Drupal, utilizzato per testare l'unità della completezza di una singola funzionalità. Se una funzione, per sbaglio, presenta delle dipendenze impreviste (ad es. Un modulo da cui dipende la funzione, che non è abilitato nella Sandbox), è qui che la dipendenza diventerà chiara.
- Sito di gestione temporanea : qui è dove vengono consegnate una o più funzionalità (create in un sito di sviluppo). Potrebbe essere solo un aggiornamento rapido per qualche problema di produzione, oppure potrebbe essere dove è consolidato tutto lo sviluppo per una nuova versione del sito Web. Se esistono conflitti tra più funzionalità, questo è l'ambiente in cui verranno prima visualizzati ... e devono essere risolti in qualche modo.
- Sito di controllo qualità : dopo che l'ambiente di gestione temporanea è stato considerato stabile, è tempo di passare alle funzionalità pertinenti e renderle disponibili anche a un livello superiore dove possono essere utilizzate per test di controllo qualità, test di accettazione, test di volume, ecc. A questo livello dovrebbe essere estremamente attento nel consentire eventuali modifiche aggiuntive (se presenti). Perché una tale modifica può invalidare tutti gli sforzi di test precedenti già completati in questo ambiente.
- Sito di produzione ombra : per preparare l'attivazione nella produzione reale, è possibile innanzitutto promuovere ulteriormente le funzionalità pertinenti in un ambiente considerato copia (ombra) del proprio ambiente di produzione reale. Se a questo punto durante il processo di migrazione qualcosa si interrompe ancora, allora quella è una bandiera rossa per ripristinare alcuni dei passaggi precedenti. Risolvilo e riprova, fino a quando tutte le parti coinvolte non approvano le modifiche.
- Sito / i di produzione - Se hai completato tutti i passaggi precedenti, questo passaggio dovrebbe essere autoesplicativo e piuttosto semplice. A seconda delle tue esigenze, questo potrebbe essere un singolo sito o qualcosa di equivalente ai siti multipli di Drupal, mentre tutti i siti coinvolti eseguono le stesse versioni di tutte le funzionalità.
- Sito di base - Nella mia esperienza, non ci sono molte implementazioni Drupal (se non del tutto) in cui questo tipo di sito viene utilizzato (anche). È semplicemente una copia dei siti di produzione, ma è disponibile per gli sviluppatori Drupal, i tester, ecc. Che può essere utilizzato per verificare l'aspetto dei siti di produzione o per eseguire la formazione degli utenti, ecc. E in qualsiasi momento un nuovo sviluppo viene avviato il ciclo, i componenti di un sito che saranno interessati (devono essere modificati) devono essere "copiati in qualche modo" utilizzando questo sito di base come input, con come target un sito di sviluppo personale .
Ovviamente, l'inventario di cui sopra dei tipi di siti Drupal è come il mondo ideale. A seconda delle dimensioni del team di sviluppo e / o dei budget disponibili per crearli e gestirli, non tutti possono essere utilizzati (o abbordabili). Questo inventario è modellato sulle migliori pratiche nel settore dell'SCM, utilizzato principalmente in tutte le grandi società globali (banche, compagnie aeree, ecc.).
5 - Moduli correlati
Braccio forte
Il modulo Strongarm consente di esportare variabili (di moduli che memorizzano le loro impostazioni in variabili) con il modulo Caratteristiche.
Esportazione nodo
Il modulo di esportazione Nodo consente agli utenti di esportare nodi e quindi importarlo in un'altra installazione di Drupal.
Esportazione ruolo
Il modulo Export Role consente ai ruoli di avere machine_names e genera un id ruolo unico (rid) basato su machine_name. I ruoli possono essere esportati con le funzionalità e ottenere lo stesso esatto ridimensionamento se importati su altri siti.
Funzionalità bandita
Il modulo Feature Banish consente di escludere completamente i singoli componenti delle funzionalità dall'interfaccia utente delle funzionalità e le esportazioni di funzionalità. Ecco una citazione al riguardo dalla sua pagina del progetto:
Questo modulo è utile quando ci sono componenti di funzionalità che si desidera assicurarsi che NON vengano mai esportati. Se stai utilizzando funzionalità per la creazione o la distribuzione di siti, probabilmente hai riscontrato il problema di qualcuno che ha esportato accidentalmente variabili di data e ora come cron_last o update_last_check. Potresti anche voler eliminare le autorizzazioni per i moduli sviluppatore in modo che non vengano coinvolti con le altre autorizzazioni del sito che desideri esportare. Gli articoli espulsi non verranno visualizzati nel modulo funzione O IN QUALUNQUE ALTRO MODULO DI CARATTERISTICHE, pertanto utilizzare con cautela. Per un elenco centrale di funzionalità che non devono mai essere esportate, consultare https://www.drupal.org/node/2400531
FAGIOLO
Il modulo Bean rende i tuoi blocchi esportabili. Ecco una citazione al riguardo dalla sua pagina del progetto:
Pensa a un Bean come a un metodo per fornire nuovi tipi (rispetto al nodo sarebbe un tipo di contenuto) che fornisce quindi un'interfaccia di aggiunta del contenuto per creare tutti i blocchi di cui hai bisogno (vedi screenshot sotto). Il contenuto del bean può quindi essere posizionato attorno al sito come qualsiasi altro blocco.
Questo modulo funziona perfettamente anche in combinazione con i moduli di integrazione delle funzionalità UUID e UUID . Questo modulo è iniziato solo dalla D7, ma è già stato incluso con il core Drupal 8. Tutorial video Tutorial del modulo Drupal Bean - l'utilizzo dell'interfaccia utente di Bean Admin fornisce un'ottima introduzione per comprendere davvero la potenza di questo modulo e il tipo di cose che puoi fare con esso (usando solo tecniche di costruzione del sito, senza codifica personalizzata).
Habitat
Il modulo Habitat ha molto senso in un flusso di lavoro basato sulle funzionalità . Ecco una citazione al riguardo dalla sua pagina del progetto:
In una configurazione multi-ambiente (ad es. Prod, test, dev, local) ci sono alcuni moduli che si desidera abilitare o disabilitare sempre in determinati ambienti. Ogni volta che si sincronizza un database, è necessario riattivare / disabilitare gli stessi moduli. Peggio ancora, diventi pigro e mantieni abilitati i moduli di sviluppo in produzione.
Habitat fornisce impostazioni per abilitare o disabilitare determinati moduli su ciascun ambiente (habitat). Basta impostare una variabile con ad esempio $ conf ['habitat'] = 'local'; nel tuo file settings.php (la variabile effettiva da usare è configurabile per il tuo flusso di lavoro corrente). I moduli di disabilitazione / abilitazione vengono eseguiti su hook_init.
6 - Risorse consigliate:
7 - Possibili alternative all'utilizzo delle funzionalità
Se non sei in grado, o non sei disposto (ancora), ad usare le Funzionalità , allora potresti voler verificare in che misura gli approcci / i moduli sottostanti potrebbero fornire qualche tipo di alternativa.
Esportazione / importazione manuale
Queste sono le strutture comunemente note (per evitare le funzionalità di parola ...) disponibili tramite l'interfaccia utente dell'amministratore, per moduli come Regole , Viste , ecc. (Elenco incompleto!).
Copia bundle
Alcune persone considerano il modulo di copia Bundle come una possibile alternativa. Ha supporto di esportazione / importazione per:
- Tipi di nodo.
- Tassonomia.
- Utente.
- Campi API campo.
- Gruppi di campi.