16/06/2017
Bedrock, la nostra salsa per WordPress
È un software le cui linee guida di sviluppo sono piuttosto lasche e permette di fare “porcherie” facilmente. Ma poi…
Era metà del 2014.
All’ennesimo progetto aperto con WordPress in cui cercavo un modo furbo per non dover committare tutto il suo core dentro il repository Git e combattevo con la possibilità di deployare in maniera furba i nostri progetti, mi imbatto in questo sito. Giuro, appena visto quasi piango.
Il suo nome richiama alla famiglia Flintstones e la cosa mi garbava. Ma facciamo un passo indietro.
I problemi più comuni prima di Bedrock
Cominciare un nuovo progetto con WordPress vanilla aveva il difetto di dover ripetere molte volte lo stesso tipo di operazioni: ad esempio utilizzando serialmente plugin base comuni a molti progetti – sia benedetto Advanced Custom Field Pro, ma di questo parlerò un’altra volta – ci trovavamo sempre a copia-incollare centinaia di file. Non avevamo trovato (ancora) un modo furbo per gestire le dipendenze sui plugin.
Inoltre avere degli ambienti di sviluppo locale, staging e produzione implicava avere in .gitignore il file wp-config.php (ovvero quello in cui ci sono le configurazioni di connessione al db).
Infine l’aggiornamento di plugin e core avveniva sempre pericolosamente.
Visto che core e plugin risultavano sotto versionamento, la possibilità di incorrere in conflitti e altre gioie di Git era piuttosto alta, oltre ad avere spesso installazioni datate di plugin e WordPress stesso. Dal momento che WP è una delle piattaforme consumer più usate al mondo è anche una delle più prese di mira per tentare di bucarle, gli aggiornamenti sono un fattore cruciale per tutti.
I benefici più grandi per noi(s3)
Innanzitutto possiamo ora essere sicuri di alcune cose.
Abbiamo configurazioni separate per diversi ambienti di sviluppo e questo è ovviamente molto bene. Inoltre abbiamo guadagnato una gestione di variabili d’ambiente (quali ad esempio configurazioni di connessione al database) in un file .env e non dentro lo stesso file di configurazione wp-config.php. Implica che ognuno di noi può avere l’ambiente locale che preferisce – pur secondo certe best practice – ma non impedisce od ostacola gli altri.
Altra apparentemente piccola ma significativa differenza: le cartelle di configurazione di Bedrock non sono esposte al webserver.
La gestione delle dipendenze è gestita da Composer (uno standard de-facto per lo sviluppo PHP come packet manager) e permette anche l’uso di sorgenti private, quindi plugin sviluppati internamente oppure versioni premium ma conservate in un git repository privato. Quindi aggiorni una versione di un plugin, sistemi i file di compose dei progetti, fai girare lo script di update e tutti i siti sono aggiornati.
MAI. PIÙ. SENZA.
Qui di seguito riporto uno screenshot comparativo che i più nerd apprezzeranno.
Facciamolo (capi)strano.
Fin qui però non abbiamo ancora risolto l’annoso problema di portare i siti in staging, pre-produzione, produzione etc. senza addannarsi l’anima. In altre parole non avevamo ancora superato il problema del rapporto conflittuale con FTP. Rapporto particolarmente complicato tutte le volte che le modifiche sono massive o allo stesso modo puntuali.
- Problema 1. Devo modificare una cosa in produzione, sono tentato di modificare il file direttamente lì e mi dimentico di riportare la modifica su Git. Pratica sporca, usata spesso, ma superabile. Avevamo trovato ad esempio git-ftp che risolve in parte il problema. Ma non era sufficiente.
- Problema 2. Devo spostare velocemente il tutto da un ambiente di staging a quello di produzione con poco più di un comando, lo devo fare iterativamente perché devo testare le modifiche prima di rompere tutto.
Welcome (back) to Capistrano
Qualche anno prima, quando eravamo pazzi e usavamo solo Drupal, ci eravamo imbattuti nel lavoro degli allora Twinbit che avevano reso Drupal, assieme a Features e un po’ di altri moduli, compatibile con capistrano. Una libreria ruby on rails che permette di eseguire comandi remoti da locale come ad esempio deployare un sito ovvero di rollbackare la versione quando questa non funziona, senza dover intervenire manualmente su ogni file modificato.
Esiste quindi un concetto di release che viene sparata su un server e che semplicemente viene riprodotta identica.
La stessa cosa, fortunatamente, usiamo da anni anche nel caso di Bedrock che, con l’estensione bedrock-capistrano, ci permette di portare in produzione una nuova release al costo del comando
cap production deploy
che certamente una svolta.
Perché?
Perché tutta la parte di core, di plugin pubblici e proprietari e di temi, viene buildata a partire dai sorgenti. Quindi per ogni release si riscarica il core pulito, i plugin puliti, il tema pushato sul repository e viene costruita una copia carbone del sito soltanto della ultima versione disponibile di tutto questo ben di Dio.
Immaginate lo scenario: cliente chiama perché hanno bucato sito. Può succedere, succederà.
Una volta fatta una verifica di integrità delle parti custom e sanitizzate le parti relative agli upload, basta lanciare una build per ripulire tutto e ricostruirlo.
Tempo stimato 30-80″ circa.
Gli upload, citavo. Ecco questi, assieme ai file di connessione al database e ad altri file che devono essere persistenti rispetto alle build, sono linkati simbolicamente (in nerdese symlinkati) così da evitare di perdersi storico.
Confesso, la prima versione di nois3.it era su WordPress vanilla, il passaggio a Bedrock l’ho fatto direttamente sotto al culo di WordPress e non si è accorto di nulla, fatto solo lo spostamento di tutti gli allegati ai post.
Ma ammettiamo per un secondo che abbiate sbagliato a deployare. Panico, vero? No.
cap production deploy:rollback
Il tempo di un deploy ed è tutto su, se prima funzionava. Caruccio.
I benefici più grandi per i nostri clienti.
La certezza di poter replicare le modifiche su produzione senza intralciare il lavoro. La praticamente totale assenza di down perché “stiamo mettendo online modifiche”. Una volta terminato il deploy, il sistema si preoccupa di linkare sempre la cartella current, quindi una volta aggiornato il webserver, punta automagicamente all’ultima versione della release.
Sicurezza, come scrivono nel loro sito.
Modularità.
Ordine e gestione delle dipendenze.
I treni passeranno in orario… no questo no, però insomma.
Alcuni limiti
Ci sono alcuni limiti, più all’approccio al progetto che altro. A volte sembrano passare per vendor lock-in ma non è affatto così.
In pratica la cosa che più pesa è un server diverso dagli hosting da pochi euro. Serve un accesso SSH, serve una configurazione particolare di Apache o Nginx, servono alcune accortezze che un sistemista medio sa fare senza problemi e che invece l’hosting non può.
Implica quindi un costo più alto e una curva di adozione più ripida.
Posso avere un FTP per lavorarci?
No.
Ma non perché siamo cattivi, ma perché oggettivamente FTP significa lavorare direttamente sul filesystem di produzione nella stragrande maggioranza dei casi e la risposta sarà semplicemente no.
Si può lavorare in più società, più soggetti, più fornitori. Ma si lavora secondo uno standard moderno e condiviso.
Posso avere un FTP per uploadare cose?
Certo, volendo. Ma sei sicuro che serva?
Cosa cambia per i backup?
Nulla quelli li devi fare lo stesso, o meglio tanto: è inutile backuppare tema e plugin. Sono sul composer.json che è committato su un repository. E poi ci sono i file e il database. Meglio, parecchio meglio.
Usate Bedrock? Ce lo fate sapere?