Il mio ambiente di sviluppo locale e come effettuo gli aggiornamenti in produzione

Sono un utente Mac e, per quanto abbia familiarità con Docker, ho sempre utilizzato software di sviluppo locale per una questione di praticità. Negli ultimi mesi, tuttavia, sono passato da MAMP a LocalWp: questo software rende molto semplice creare un ambiente di sviluppo pronto all’uso e affidabile e offre una funzione molto comoda per clonare i progetti.

Lavorando per piccole agenzie e clienti privati, mi capita spesso di utilizzare gli stessi plugin, lo stesso tema di base e le stesse configurazioni. Grazie a LocalWp posso creare un sito di partenza con tutto ciò di cui ho bisogno già pronto e configurato e, con un solo clic, clonarlo per iniziare un nuovo progetto. LocalWp offre anche altre funzionalità molto utili, come wp-cli, i backup e l’ottimizzazione delle immagini, che mi fanno risparmiare molto tempo.

In un prossimo post spiegherò in dettaglio i plugin che utilizzo, le configurazioni e altri aspetti relativi alla creazione dei miei siti monolitici di vetrina e di e-commerce, ma per ora supponiamo di aver completato la realizzazione del sito e di averlo trasferito in produzione con un semplice duplicatore, così da poter passare ad altre informazioni che desidero condividere con voi in questo articolo.

Nella maggior parte dei miei progetti, a meno che non si tratti di funzionalità specifiche che intendo riutilizzare in più progetti, scrivo tutto il codice relativo alle funzionalità specifiche del sito, agli stili e agli elementi personalizzati (li chiamo “elementi” poiché utilizzo un tema premium che si avvale di WPBakery) all’interno di un tema figlio.

Vediamo ora come organizzo questo tema figlio e come mantengo la sincronizzazione tra l’ambiente locale e quello di produzione
. Su questo repository ho caricato il mio tema di partenza, che è un tema figlio che utilizza Salient come tema padre. All’interno di questo progetto potrete trovare gli elementi standard di un tema figlio, come i file `style.css` e `functions.php`, ma ho deciso di aggiungere Parcel per la gestione dei file `.scss`, che trovo molto pratico, e una GitHub Action per la pubblicazione diretta ad ogni push tramite FTP.

Vediamo le due configurazioni in dettaglio.

Parcel
Ho deciso di adottare Parcel perché è uno strumento di build che non richiede alcuna configurazione. Nel mio caso, come potete vedere dal progetto, ho dovuto solo aggiungere una dipendenza “parcel-namer-custom” per avere nomi dei file di output fissi anziché variabili, il che mi permette di inserirli in coda da functions.php.

Azione
GitHub Al seguente percorso .github/workflows/main.yml troverete un job molto interessante per la pubblicazione in produzione del tema ad ogni push, con l’aggiunta del file .gitignore che permetterà a GitHub di ignorare gran parte del codice necessario solo nell’ambiente di sviluppo. Questi due file insieme ci permetteranno di pubblicare solo i file .php e .css necessari. Ovviamente un approccio migliore sarebbe quello di consentire il commit di tutto il codice ed escludere in questo job, tramite l’istruzione `exclude`, la pubblicazione dei file di sviluppo, oppure avviarlo solo al commit sul branch `main` e utilizzare un branch `development`.

Come ho scritto sopra, un secondo scenario riguarda i plugin, per i quali scrivo codice che deve essere pubblicato non solo su un sito web, ma che è rilevante per molti altri progetti. Condividerò con voi la mia soluzione per avere un repository privato e aggiornamenti automatici di WordPress in un prossimo articolo.

Se le informazioni contenute in questo articolo vi sono state utili, vi consiglio di passare al prossimo articolo di questa serie: https://blog.riccardodicurti.it/my-thoughts-on-css