Distribuzione continua di WordPress e controllo della versione con Bitbucket

Va bene, gente. È ora di 'sventare.

Se sei come me, hai trascorso la prima parte dei tuoi anni di sviluppo di WordPress "cowboy coding", ovvero apportando modifiche selvagge su siti live, testandoli urgentemente e attivandoli con FTP, spesso risultando in 500 messaggi di errore interni del server e Tutto il sito interrompe tutto visibile ai tuoi stimati visitatori.

Anche se questo è stato assolutamente elettrizzante mentre l'adrenalina pompava tra le dita, martellando in quel punto e virgola dimenticato, su siti con più di 0 visitatori (che in realtà hanno notato i tempi di inattività), questo avrebbe iniziato a diventare un problema. Se un albero cade e non c'è nessuno a sentirlo, fa rumore? Dipende dalla teoria dell'umanità a cui ti iscrivi.

Tuttavia, se un sito si arresta in modo anomalo e qualcuno è lì per vederlo, emetterà sicuramente un suono.

Distribuzione continua di WordPress eseguita in modo errato

Entra nei siti di staging, duplica le installazioni di WordPress (almeno in teoria) dove potrebbero essere apportate modifiche, quindi esegui nuovamente sul sito live una volta che tutto è stato confermato funzionante. Anche se questo ha calmato i visitatori, ha iniziato a indurre noi sviluppatori a fare rumore. Improvvisamente, dovevamo tenere traccia di due siti, assicurarci che il codice fosse sincronizzato manualmente tra di loro e testare di nuovo tutto per assicurarci che funzionasse sul sito live. Liste lunghe e disordinate di "assicurati di cambiarlo dal vivo" e "assicurati di attivarlo sul sito di staging prima di copiare il codice" erano a dir poco snervanti. Anche i backup di questo sistema erano un incubo: una sfilza di cartelle denominate "my-theme-staging-1" e "my-theme-live-before-menu-restyle-3" e così via.

Ci doveva essere un modo migliore, e c'era.

C'era Git, che offre un perfetto controllo del codice sorgente e altre funzionalità agli sviluppatori. L'utilizzo del controllo della versione per le installazioni di WordPress ha accelerato e ripulito immediatamente lo sviluppo, poiché le ore non venivano più spese per il backup in un sistema per sviluppatore, ma in realtà per la codifica. Le modifiche sono state salvate e ho finalmente potuto aggiungere messaggi significativi al mio lavoro, mondi diversi da "my-theme-4-v2".

Sebbene la base di codice fosse molto più pulita, restava il problema delle distribuzioni effettive e della garanzia che il sito in questione utilizzasse il codice più recente: immettere l'opportunità per l'errore umano. Fare ancora affidamento sui caricamenti FTP manuali che sovrascrivono il codice precedente non è stato eccezionale. Sebbene esistessero altri servizi CI/CD, molti di essi avevano un prezzo notevole e una grande quantità di configurazione: riconfigurazione del server, affidamento su un altro servizio anche per il sito Web più semplice, apprendimento dell'intero "modo di fare le cose" dell'altro servizio e tutto le idiosincrasie che ne derivano.

Mentre configurazioni simili a questo tutorial possono essere eseguite con GitHub/GitLab e altri servizi, avevo messo le mie uova nel carrello Atlassian all'inizio a causa dei loro repository privati ​​​​gratuiti (che è stata solo un'offerta recente di GitHub). Quando Bitbucket ha introdotto i propri servizi Pipelines e Deployments , ha consentito al nuovo codice di essere distribuito automaticamente a siti di staging o di produzione (o qualsiasi altro sito intermedio) senza ricaricare tramite FTP o utilizzare un servizio esterno. Gli sviluppatori possono ora utilizzare tutti i valori del controllo del codice sorgente nello sviluppo di WordPress e inviare istantaneamente tali modifiche alle destinazioni appropriate senza ulteriori clic o sequenze di tasti, con lo stato di tutto visibile tramite un'unica dashboard. Ciò garantisce che tutto rimanga sincronizzato e, a colpo d'occhio, ti consente di sapere esattamente quale codice è in esecuzione su ciascun sito. Inoltre, il prezzo per i minuti di build di Bitbucket è incredibilmente conveniente, con 50 minuti gratuiti al mese e un'opzione per un piano "Gratuito con eccedenze".

Ci è voluto un po' di tempo all'avvio per capire come utilizzare al meglio i rami e altre funzionalità del controllo del codice sorgente in questo nuovo modello e i dettagli della configurazione di Bitbucket Pipelines. Ecco il processo che utilizzo per avviare nuovi progetti WordPress. Non entrerò in tutto il nocciolo della questione sulla configurazione dell'installazione di git e WordPress poiché grandi risorse per questo sono solo una ricerca su Google. Alla fine, il flusso di contenuti sarà qualcosa del genere:

La routine di distribuzione di WordPress di Alexa Green

I passaggi qui descritti dovrebbero essere eseguiti secondo necessità:

Sul server del cliente

Imposta un dominio per il sito live (ad esempio, clientsite.com) e un sottodominio per lo staging (ad esempio, staging.clientsite.com).

Installa WordPress sia sul sito live che sul sottodominio di staging. Questo può essere fatto tramite cPanel/Softaculous (se l'hosting del cliente lo ha) o scaricando da wordpress.org. Assicurarsi che vi siano database separati rispettivamente per il live e lo staging.

Su Bitbucket.com

Configura un nuovo repository. Includere un .README per aiutarci a iniziare.

Nel repository, Impostazioni > Pipeline > Impostazioni , quindi seleziona Abilita pipeline .

In Impostazioni > Pipeline > Variabili del repository , inserisci quanto segue:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Torna a Pipelines > Impostazioni e fai clic sul pulsante Configura bitbucket-pipelines.yml . Seleziona PHP come lingua nella pagina seguente. Ti consigliamo di utilizzare qualcosa come il seguente codice. Assicurati di sostituire la versione PHP con quella che stai utilizzando sul server del client e gli URL/server FTP con gli URL/server FTP del sito client effettivo (produzione e staging).

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Fare clic su Conferma file . La configurazione delle pipeline ora verrà eseguita e verrà eseguita.

Se tutto viene distribuito correttamente, torna indietro e modifica il file bitbucket-pipelines.yml (puoi arrivarci tramite Pipelines > Settings e View bitbucket-pipelines.yml ). Ti consigliamo di sostituire entrambi i posti in cui dice git ftp init con git ftp push e save/commit. Ciò assicurerà che vengano caricati solo i file modificati, risparmiando così minuti di build. Il tuo file bitbucket-pipelines.yml dovrebbe ora leggere:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Aggiungi un ramo chiamato main-dev .

Sulla tua macchina locale

Clona il repository in una directory vuota che desideri utilizzare per l'installazione locale. Dai un'occhiata al ramo main-dev .

Configura un'installazione WP locale in questa directory. Ci sono molti strumenti per questo: Local by Flywheel, MAMP, Docker, ecc. Assicurati che tutto sia lo stesso (versione WordPress, versione PHP, Apache/Nginx, ecc.) di quello che è in esecuzione sul server del client.

Aggiungi un .gitignore che assomigli a questo. In sostanza, vogliamo che Git ignori tutto tranne wp-content (per evitare problemi di installazione tra le installazioni). Potresti anche voler aggiungere le tue regole per ignorare i file di backup di grandi dimensioni e le icone create dal sistema e i file DS_Store.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Salva e .gitignore .

Apporta le modifiche e impegna di conseguenza.

Ogni volta che ti impegni su main-dev, verrà attivato un caricamento FTP sul sito di staging. Ogni volta che ti impegni a master, verrà attivato un caricamento FTP sul sito di produzione. Nota che questo utilizzerà i minuti di compilazione, quindi potresti voler apportare la maggior parte delle modifiche locali su un ramo di main-dev, quindi unirti a main-dev una volta che hai finito per la giornata.

L'unione di main-dev in master porterà tutte le modifiche allo staging attive. Puoi controllare lo stato di pipeline e distribuzioni nel repository su Bitbucket.org.

Sincronizzazione dei database di WordPress attraverso le installazioni

Tieni presente che quanto sopra sincronizzerà solo i file (temi, plug-in, ecc.). La sincronizzazione del database tra produzione e staging diventa una questione diversa, poiché spesso i clienti apportano modifiche al sito live che non si riflettono sul sito di staging e viceversa.

Per sincronizzare i database tra le installazioni di WordPress, esistono diverse opzioni. Tradizionalmente, puoi aggiornare i database importando/esportando tramite phpmyadmin . Questo è complicato, tuttavia, poiché non può aggiornare alcune cose che devono essere aggiornate, come i permalink nei contenuti dei post. Utilizzando questo metodo, uno strumento preferito è il plug-in Velvet Blues Update URLs, che puoi quindi utilizzare per cercare/sostituire qualsiasi istanza del vecchio URL del sito (ad esempio, https://staging.clientsite.com) con il nuovo URL del sito ( ad esempio, https://clientsite.com). Puoi anche usarlo con percorsi e stringhe relativi. Questo metodo finisce per lasciare molto spazio all'errore umano: se una stringa sostituita viene scritta in modo errato, può causare l'interruzione dell'intero sito e l'impossibilità di utilizzare il plug-in/di accedere alla dashboard.

Sebbene un plug-in come All-in-One WP Migration offra una funzione di ricerca/sostituzione pronta all'uso ed è incredibilmente intuitivo, porta anche file, annullando così i valori dell'intero flusso di lavoro di Pipelines. Inoltre, poiché reimporta tutti i wp-upload, può causare file e tempi di caricamento enormi (quindi non è adatto per spostare le modifiche tra le installazioni). Un plug-in come questo è meglio riservato ai backup dell'intero sito per scopi di archiviazione/sicurezza.

VersionPress sembra una soluzione interessante, ma non è ancora stata provata in molti ambienti di produzione. Per ora, plugin come WP Sync DB o WP Migrate DB Pro sembrano essere le migliori soluzioni per la gestione dei database. Consentono di eseguire il pull/push dei database attraverso le installazioni offrendo al contempo la possibilità di aggiornare automaticamente URL e percorsi. Possono migrare solo alcune tabelle, come wp_posts solo per i contenuti dei post, senza perdere tempo a reimportare utenti e impostazioni a livello di sito. Mi piace sempre estrarre dal vivo per assicurarmi che i dati di produzione non vengano sovrascritti. Ecco un esempio di configurazione se stai utilizzando WP Sync DB (altre procedure dettagliate disponibili su WP Sync DB github):

1. Sul sito live: configura WP Sync DB con l'impostazione "Consenti pull da questo repository" abilitata.
2. Sul sito di staging: configura WP Sync DB con le impostazioni Pull from Live. Chiamalo "dal vivo alla messa in scena".
3. Sulla configurazione dello sviluppatore locale: configura WP Sync DB con le impostazioni Pull from Live. Chiamalo "live-to-dev".

Potresti anche voler impostare una regola di push "dev-to-staging" e controllare l'impostazione del sito di staging per consentire la sovrascrittura del database.

Avvolgendo

Ho scoperto che questi metodi tendono a funzionare per la maggior parte dei casi d'uso, sia nello sviluppo di un nuovo sito Web WordPress che per la riprogettazione/riconfigurazione di un sito già attivo.

Consente distribuzioni di codice che mantengono aggiornate tutte le versioni del sito senza ulteriori tempi/fatiche di sviluppo e logica di migrazione del database intenzionale e sicura per lavorare tra i siti. Anche l'aggiornamento dei plug-in viene eseguito all'interno del controllo del codice sorgente, quindi gli aggiornamenti dei plug-in possono essere verificati in sicurezza durante lo staging prima di eseguire il commit sul sito live, riducendo così al minimo le interruzioni del sito di produzione.

Sebbene vi sia sicuramente spazio per miglioramenti per portare più flusso di lavoro di controllo del codice sorgente nella gestione del database, fino a quando uno strumento come VersionPress non viene utilizzato maggiormente negli ambienti di produzione, questo metodo di pull/push selettivi del database tramite WP Sync DB o WP Migrate DB Pro sembra essere il metodo più sicuro per affrontare questo problema. Curioso di sapere cosa funziona per il tuo flusso di lavoro WordPress, o se dopo tutto questo preferisci semplicemente prendere il tuo lazo e codificarlo da cowboy!