Implementazioni moderne per i tuoi siti WordPress

Se sei come me, la tua prima esperienza con il push di file su un server Web è stata tramite un file manager basato sul Web come cPanel o un client FTP (File Transfer Protocol) come Transmit o Filezilla. Collegati al server, trascina i tuoi file e attendi il completamento del trasferimento.

Facile, vero?

Tuttavia, non appena ho iniziato a lavorare con qualcosa di più complesso dei file HTML statici, la distribuzione del mio codice è diventata molto più complessa: cosa succede se mi manca un file richiesto da altri, o un punto e virgola in un'inclusione globale e scherma in bianco il intero sito? Cosa succede se un passaggio cruciale viene perso durante il processo?

Questi problemi di "codifica da cowboy" peggiorano solo quando vengono coinvolte più persone, ambienti e dipendenze. Di conseguenza, diventa sempre più difficile continuare a fare progressi mentre si destreggiano tutte queste parti mobili. Peggio ancora, il rilascio del codice diventa un grosso problema e una costante fonte di ansia.

Man mano che le nostre applicazioni, i siti e i negozi diventano più moderni, dovremmo modernizzare anche le nostre implementazioni. Dal controllo della versione alla distribuzione continua, un moderno processo di rilascio può alleviare l'ansia relativa alle distribuzioni.

Monitoraggio delle modifiche con il controllo della versione

Il primo passo per allontanarsi dagli aggiornamenti ad hoc e dalla codifica cowboy è mettere il tuo sito sotto il controllo della versione, usando uno strumento come Git.

L'uso del controllo della versione significa che sarai in grado di vedere cosa è cambiato, chi ha apportato le modifiche e persino lavorare su più set di modifiche contemporaneamente utilizzando i rami. Di conseguenza, il lavoro non viene sovrascritto e gli eventuali conflitti tra i file vengono chiaramente evidenziati.

Se non hai mai lavorato con Git prima, non temere: abbiamo scritto sia un'introduzione a Git che un post sui flussi di lavoro Git più avanzati.

Decidere cosa monitorare

Mentre spostiamo il nostro sito sotto il controllo della versione, ciò di cui non teniamo traccia è importante quasi quanto ciò che facciamo:

In generale, il controllo della versione serve a tenere traccia del codice sorgente, non delle risorse generate da strumenti o processi . Ciò include cose come CSS e JavaScript concatenati/minimizzati, dipendenze esterne, ecc. Collettivamente, ci riferiamo a questi elementi come artefatti .

Ad esempio, se stai utilizzando un preprocessore CSS come Sass, i file CSS generati non dovrebbero essere tracciati sotto il controllo della versione. Non solo sono facilmente riproducibili, sono difficili da leggere e una fonte comune di conflitti di unione quando sono coinvolti più sviluppatori.

Quando si tratta di dipendenze (librerie, plugin di WordPress, ecc.), sfrutta strumenti come Composer e WPackagist piuttosto che raggruppare codice di cui non sei responsabile nel tuo repository.

Inoltre, un repository Git non dovrebbe mai contenere cose come password, chiavi SSH private o altre informazioni riservate che sarebbero considerate segrete , poiché ogni sviluppatore con una copia del repository avrebbe quindi quelle informazioni riservate sui propri computer.

Strutturare il tuo repository

Quando si configura un repository Git per un sito WordPress o WooCommerce, generalmente è meglio trattare wp-content/ come radice del repository, poiché generalmente non toccherai i file al di sopra di questa directory.

I plugin e i temi utilizzati dal tuo sito ma per i quali non stai mantenendo il codice dovrebbero quindi essere caricati tramite Composer, poiché sono dipendenze esterne. Allo stesso modo, i file CSS e JavaScript elaborati dovrebbero essere esclusi tramite il file .gitignore, poiché questi artefatti verranno creati per noi come parte del nostro processo di rilascio.

Abbiamo un modello di repository gratuito disponibile su GitHub per iniziare.

Un'introduzione a CI/CD

Quando si tratta di distribuire il software, ci sono due termini importanti da comprendere: Continuous Integration (CI) e Continuous Delivery (CD).

Questi due termini sono strettamente correlati, tanto che sono spesso indicati collettivamente come “CI/CD”, e il percorso attraverso il quale fluiscono i nostri cambiamenti diventa così la “conduttura CI/CD”. Questa pipeline di solito assume la seguente forma:

1. Costruisci la versione: installa le dipendenze (Composer, npm, ecc.), quindi crea gli artefatti (Webpack, Grunt, Sass, ecc.)
2. Testare la build: eseguire unit test, controllare gli standard di codifica, eseguire analisi del codice statico, ecc.
3. Distribuire la versione in uno o più ambienti

L'integrazione continua è il processo di test continuo del nostro codice per garantire che le modifiche non interrompano le funzionalità esistenti, in modo che le nostre nuove modifiche si integrino perfettamente con la base di codice esistente. Ogni volta che vengono inviate nuove modifiche, vengono eseguiti controlli per garantire che non stiamo "interrompendo la build".

Affinché l'integrazione continua sia utile, questi controlli devono essere automatizzati. Ad esempio, se disponi di una suite di unit test, puoi scegliere di eseguire questa suite di test ogni volta che viene aperta una nuova richiesta pull, avvisandoti di possibili rotture prima che il codice entri in produzione.

L'integrazione continua non si limita agli unit test, tuttavia, poiché esistono numerosi controlli "senza codice" che possono essere eseguiti automaticamente rispetto al codice, tra cui:

• Controlli degli standard di codifica (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Analisi del codice statico (PHPSan, Salmo)

L'esecuzione automatica di questi controlli ad ogni push garantisce inoltre che tutto il codice venga eseguito attraverso gli stessi controlli, impedendo il rilascio del codice che non passa.

La Continuous Delivery , d'altra parte, è l'idea che dovremmo essere in grado di "consegnare" (distribuire) il nostro codice in un dato momento. A tal fine, dobbiamo disporre di un processo di distribuzione basato su script che, con il semplice clic di un pulsante, sposterà senza problemi il nostro codice in produzione.

Avere le tue implementazioni sottoposte a script significa che puoi distribuire sia regolarmente che in modo coerente ; ogni distribuzione dovrebbe funzionare come quella precedente. Di conseguenza, il tuo team può schierarsi più regolarmente con un livello di fiducia più elevato e meno preoccupazioni che qualcuno abbia perso un passo lungo il percorso. Per alcune squadre, non è raro schierare dozzine (o addirittura centinaia) di volte al giorno!

A seconda del tuo sito, potresti anche voler esaminare "l'altro CD", distribuzione continua ; è molto simile alla consegna continua, ma in questo modello ogni push a un ramo viene distribuito automaticamente. Questo può essere estremamente potente quando si utilizza uno schema di controllo della versione ramificato (come Github Flow), ma potrebbe essere indesiderabile se è necessario pianificare le finestre di rilascio o eseguire tutto il lavoro nel ramo principale.

Implementazione di un sito WordPress o WooCommerce con CI/CD

Ora che abbiamo una conoscenza della terminologia di base, diamo un'occhiata alla distribuzione di un tipico sito WordPress o WooCommerce:

Per questo esercizio utilizzeremo Branch, uno strumento CI/CD progettato in base alle esigenze degli sviluppatori di WordPress dalle stesse persone dietro WP Pusher. Soprattutto, Branch ha il supporto integrato per la distribuzione su Nexcess!

Per iniziare, iscriviti a Branch collegando il tuo account GitHub, GitLab o Bitbucket, quindi creando il tuo primo sito.

Successivamente, vorremo configurare tutti i passaggi necessari per costruire il nostro sito. Branch offre una serie di "ricette" per azioni comuni (installazione delle dipendenze di Composer, esecuzione di Webpack, ecc.), ma ci dà anche la possibilità di aggiungere un numero qualsiasi di passaggi personalizzati.

Dopo aver delineato i passaggi necessari per costruire il nostro sito, possiamo passare alla fase successiva della nostra pipeline: il test.

Se disponi già di una suite di test automatizzata per il tuo sito, puoi semplicemente dire a Branch di eseguire tutti i comandi necessari. Anche se non disponi già di test, Branch semplifica l'aggiunta di linting, standard di codifica e controlli di compatibilità.

Ora che abbiamo installato le nostre dipendenze, creato tutto e superato i nostri test, è tempo di mettere in produzione il nostro codice!

Branch contiene ricette per la distribuzione su Nexcess (così come altri importanti provider di hosting) e il collegamento delle due piattaforme è indolore:

1. Seleziona il tuo sito nella dashboard di Branch, fai clic su "Impostazioni", quindi prendi la chiave SSH pubblica del tuo sito Branch
2. Aggiungi questa chiave pubblica all'elenco delle chiavi all'interno del portale Nexcess

Una volta che Branch è in grado di comunicare con il tuo sito Nexcess, possiamo selezionare la ricetta di distribuzione "Nexcess" e inserire alcuni dettagli:

1. Il nome host e il nome utente del sito (disponibili tramite il portale Nexcess nella schermata "Accesso" del tuo sito)
2. La radice Web su cui stiamo effettuando la distribuzione. Se il nostro repository git è destinato a fungere da directory wp-content/, questo valore dovrebbe essere "public_html/wp-content".
3. I file che desideriamo distribuire (generalmente l'impostazione predefinita, "*", è sufficiente)
4. Il ramo git da distribuire in questo ambiente

L'impostazione "Git branch" è particolarmente importante, poiché consente di specificare distribuzioni diverse per branch diversi. Ad esempio, potresti avere un ramo di "staging" che viene distribuito nel tuo ambiente di staging, consentendoti di testare le modifiche prima di renderle attive.

Vale la pena notare che Branch utilizza il modello di distribuzione continua per impostazione predefinita, in cui la pipeline viene eseguita con ogni push al ramo specificato. Se preferisci più un modello di consegna continua (in cui è necessario intraprendere alcune azioni manuali), potresti considerare di mantenere un ramo di "produzione" in cui viene unito solo quando sei pronto per il rilascio.

A questo punto, Branch dovrebbe essere configurato per creare e distribuire il tuo repository git su Nexcess! Puoi attivare la tua prima distribuzione facendo clic sul pulsante "Esegui distribuzione" nella pagina "Pipeline" del tuo sito o spingendo al tuo repository Git.

Personalizzazione del processo di rilascio

Una delle caratteristiche davvero interessanti di Branch è la possibilità di configurare passaggi aggiuntivi dopo una distribuzione riuscita, come svuotare automaticamente la cache degli oggetti del tuo sito dopo una distribuzione. Questo può essere ottenuto utilizzando la ricetta WP-CLI in "Altro".

L'host e il nome utente saranno generalmente gli stessi utilizzati nella fase di distribuzione e puoi concatenare tutti i comandi necessari.

Conclusione

Se stai ancora lottando con le buffonate da cowboy e/o con le versioni piene di ansia, dai un'occhiata a Branch e rendi le distribuzioni un gioco da ragazzi!