Inside the Dev House: come gestiamo la distribuzione automatica dei temi per i temi WordPress LITE e PRO

Come puoi immaginare, lo sviluppo del tema è qualcosa che facciamo molto qui in azienda. Con circa 4-5 nuovi progetti tematici nelle opere in un dato momento e 80 temi la nostra directory in totale (il che significa manutenzione attiva e ulteriore sviluppo anche di quelli), abbiamo le mani piuttosto piene.


In un’impostazione come questa, alcune ottimizzazioni e persino l’automazione, ove possibile, sono fondamentali.

Quindi oggi, vogliamo invitarti attraverso la nostra porta di casa di sviluppo a ThemeIsle, per così dire, e mostrarti due pezzi specifici del nostro puzzle di sviluppo del tema.

Non nasconderò che questo tipo di post è un esperimento. Se ti piace, faremo in modo di mettere in evidenza più cose come questa in futuro.

In particolare, l’argomento di oggi è qualcosa che può essere chiamato, "distribuzione automatica e architettura di regressione visiva per lo sviluppo del tema WordPress."

Aspetta, cos’è la distribuzione automatica dei temi?

Se non parli sviluppatore, ciò che significa in inglese è che puoi sviluppare temi per WordPress, farli distribuire su un server e quindi confrontare visivamente le differenze con una linea di base predefinita senza dover fare nulla manualmente.

Succede tutto automaticamente, o meglio, "automagicamente."

Come funziona?

Abbiamo sviluppato due servizi per occuparci di questa distribuzione automatica dei temi: "Bootstrap pirata" e "Pirate Wraith."

Il primo, Pirate Bootstrap, può essere attivato tramite Webhooks da GitHub.

Su richiesta pull, distribuisce una nuova istanza di WordPress, utilizzando un determinato tema da un repository set + tutti i pacchetti e le impostazioni del database presi dalla demo predefinita del tema su ThemeIsle.

Quest’ultimo, Pirate Wraith, esegue un test di regressione visiva (ovvero confrontando immagini da due fonti). Il test verifica la nuova distribuzione del tema rispetto alla demo di ThemeIsle – visivamente – e quindi genera un rapporto. Sulla base di tale rapporto, puoi vedere rapidamente se le recenti modifiche hanno avuto un impatto sull’aspetto del tema.

In altre parole, ogni volta che stai lavorando su un tema e vuoi assicurarti che le ultime modifiche al codice non abbiano incasinato il design del tema, puoi utilizzare Pirate Wraith per gestire l’attività sul pilota automatico.

Spieghiamo ogni servizio in modo più dettagliato:

Bootstrap pirata: distribuisce una nuova istanza di WordPress usando un tema impostato

Pirate Bootstrap è ospitato su forks.themeisle.com

Pirate Bootstrap è costruito sopra WP-CLI e ha metodi per generare distribuzioni complete di WordPress basato su pacchetti di temi e dipendenze di ThemeIsle.

Gli elementi:

GitHub Webhooks

I webhook vengono utilizzati per chiamare l’API di Pirate Bootstrap su (aperte o sincronizzate) richieste pull inviando un payload JSON a http://forks.themeisle.com

Questo avvia il flusso di lavoro di distribuzione su forks.themeisle.com. Così:

Distribuzione automatica dei temi per temi WordPress LITE e PRO

Esempio di payload della richiesta pull di GitHub:

{
"azione": "ha aperto",
"numero": 1,
"pull_request": {

"testa": {
"etichetta": "Preda-Bogdan: la produzione",
"arbitro": "produzione",
"sha": "****",

"pronti contro termine": {
"id": 82166596,
"nome": "zerif-lite",
"nome e cognome": "Preda-Bogdan / zerif-lite",
"proprietario": {
"accesso": "Preda-Bogdan",

},
"privato": falso,

"git_url": "git: //github.com/preda-bogdan/zerif-lite.git",
"ssh_url": "[email protected]ithub.com: Preda-Bogdan / zerif-lite.git",
"clone_url": "https://github.com/preda-bogdan/zerif-lite.git",
"svn_url": "https://github.com/preda-bogdan/zerif-lite",

}
},

}
}

  • Noi usiamo il "sha" chiave per verificare se si tratta di una richiesta valida e se è consentito elaborare il payload.
  • Noi usiamo "accesso", "nome" e "arbitro" generare un inquilino se non esiste.

La struttura dei file

La struttura dei file sul server è impostata in modo tale da archiviare ogni tenant nella propria cartella pubblica e disporre di un’installazione principale di WordPress che utilizziamo per fare riferimento a un collegamento simbolico per ogni tenant.

La struttura del file tenant è la seguente:

inquilino/
| _ wp / / ** symlink core install di WordPress
| _ contents / / ** cartella contenuto tenant per WordPress
| | _ temi / / ** cartella temi tenant per WordPress
| | _ plugins / / ** cartella plug-in tenant per WordPress
| _ .htaccess / ** .htaccess generato automaticamente per l’inquilino
| _ vhost.conf / ** file di configurazione alias per apache
| _ wp-config.php / ** file di configurazione generato automaticamente per l’inquilino

La cartella wp / fa riferimento all’installazione principale di WordPress, che è condivisa da tutti i tenant. In questo modo, possiamo avere una singola installazione di WordPress e più istanze isolate di siti WordPress, ognuna con impostazioni incapsulate, file e risorse.

I file core e tenant di wp-config.php

Esempio di Core WordPress wp-config.php:

/ ** Percorso assoluto per la directory di WordPress. * /
require_once ($ _SERVER [‘CONTEXT_DOCUMENT_ROOT’]. ‘wp-config.php’);

/ ** Imposta le variabili WordPress e i file inclusi. * /
require_once (ABSPATH. ‘wp-settings.php’);

Esempio del locatario wp-config.php:

(I valori contenuti all’interno di parentesi graffe doppie vengono sostituiti automaticamente alla creazione dell’inquilino.)

/ ** AGGIUNTO DALL’API BOOTSTRAP * /
{{}} MYSQL_CONNECTION_TENANT_DATA

define (‘AUTH_KEY’, ‘{{AUTH_KEY}}’);
define (‘SECURE_AUTH_KEY’, ‘{{SECURE_AUTH_KEY}}’);
define (‘LOGGED_IN_KEY’, ‘{{LOGGED_IN_KEY}}’);
define (‘NONCE_KEY’, ‘{{NONCE_KEY}}’);
define (‘AUTH_SALT’, ‘{{AUTH_SALT}}’);
define (‘SECURE_AUTH_SALT’, ‘{{SECURE_AUTH_SALT}}’);
define (‘LOGGED_IN_SALT’, ‘{{LOGGED_IN_SALT}}’);
define (‘NONCE_SALT’, ‘{{NONCE_SALT}}’);

define (‘WP_DEBUG’, false);

define (‘WP_CONTENT_DIR’, ‘{{tenant_folder}} / content’);
define (‘WP_CONTENT_URL’, ‘{{tenant_folder}} / content’);
define (‘WP_PLUGIN_DIR’, ‘{{tenant_folder}} / content / plugins’);
define (‘WP_PLUGIN_URL’, ‘{{tenant_url}} / content / plugins’);

if (! definito (‘ABSPATH’))
define (‘ABSPATH’, dirname (__ FILE__). ‘/ wp’);

Dopo la creazione del tenant, viene richiesto un endpoint per recuperare i pacchetti necessari per la distribuzione dei temi (plugin, temi figlio, database). I pacchetti vengono memorizzati nella cache / memorizzati in una cartella stash sul server e vengono aggiornati ogni sei ore.

Il passaggio successivo è verificare se il tema che vogliamo distribuire è una distribuzione singola o se è necessario generare temi aggiuntivi da quello di base.

  • Se si tratta di una singola distribuzione, facciamo semplicemente un git pull usando "ssh_url" in inquilino / contenuto / temi /.
  • Nel caso in cui non si tratti di un’unica distribuzione, eseguiamo un pull git in tmp /, eseguiamo grunt generate e quindi copiamo le cartelle risultanti in tenant / content / themes /.

Il compito di generare grunt è uno standard per noi quando si lavora con temi con più versioni (di solito "Light" e "professionista") durante l’utilizzo dello stesso codebase (repository). Ad esempio, se eseguiamo grunt generate per il repository hestia-pro, avremo automaticamente anche la versione lite.

Dopo aver gestito quanto sopra, utilizziamo WP-CLI per installare tutti i pacchetti richiesti (plugin e / o temi figlio) e importare il dump del database da demo.themeisle.com.

Gli ultimi passaggi sono svuotare le regole di riscrittura .htaccess, aggiornare "indirizzo del sito" e "casa" con l’URL del tenant e l’URL per WordPress Core, aggiorna i collegamenti per voci di menu e post, quindi ricarica nuovamente apache.

Quindi inviamo all’utente un’e-mail con l’URL biforcato per la richiesta pull e il registro generato durante la distribuzione. (Ogni tenant generato segue questo modello URL generale: http://forks.themeisle.com/github-login/theme-slug/branch/)

Pirate Bootstrap – suggerimenti & trucchi e altre informazioni utili

Quando vai su forks.themeisle.com, puoi accedere a un’interfaccia simile a un terminale premendo il tasto "~" (tasto tilde) e quindi esegui un mucchio di comandi utili da lì. I più rilevanti sono:

Ripristino di una distribuzione di titolari

Il comando è tenant reimpostazione pirata [tenant] (* theme-slug) |

Esempio:

inquilino residente pirata preda-bogdan / zerif-lite / development |  

O:

inquilino residente pirata preda-bogdan / hestia / development hestia-pro |

Il comando reset riporta il conduttore al suo stato di distribuzione originale (ripristino del database, plug-in di reinstallazione e / o temi figlio).

Visualizzazione dei registri

Il comando è mostra registri. Questo comando è utile se è necessario controllare i file di registro dopo una distribuzione e non si è ancora ricevuta un’e-mail o è necessario eseguire il debug.

Nota: il file di registro viene ruotato se la dimensione del file supera i 9000 byte, quindi se non riesci a trovare quello che stai cercando, potrebbe essere necessario controllare l’archivio dei registri direttamente sul server.

Pirate Wraith: confronta visivamente due versioni di un tema

Pirate Wraith è ospitato su wraith.themeisle.com

Pirate Wraith è costruito sopra spettro e ha endpoint per interagire con le richieste di Slack, Travis e AJAX al fine di sfruttare le capacità di Wraith e generare test e report sulla regressione visiva.

Travis

Pirate Wraith espone un endpoint su wraith.themeisle.com che ascolta le richieste da una build di Travis e "non riesce" o "passaggi" la build in base ai risultati del test di regressione visiva.

All’interno del file .travis.yml, abbiamo aggiunto una nuova matrice che definisce una nuova build in aggiunta a quelle esistenti. Questo imposta le autorizzazioni per l’esecuzione di uno script bash all’interno del progetto e quindi lo esegue.

Il file YML di Travis:

matrice:
includere:
– php: "7.0"
before_install: chmod + x wraith.sh
installare:
before_script:
env: TEST_SUITE = Wraith_Visual_Regression_Testing WRAITH_FAIL = 5
script: ./wraith.sh

Potete vederlo "installare" e "before_script" vengono lasciati vuoti. Questo è di proposito, in modo che la build non erediti le azioni dalle build precedentemente definite. Siamo interessati solo a eseguire lo script bash (script: ./wraith.sh) su questa build.

Anche da notare; stiamo impostando una variabile d’ambiente chiamata WRAITH_FAIL. Questo valore viene utilizzato per indicare a Pirate Wraith qual è la differenza percentuale massima consentita per superare un test.

Lo script Bash:

#! / Bin / bash
WRAITH_SLUG = $ (nodo -pe "require ( ‘./ package.json’). wraithSlug")
WRAITH_FAIL = $ {WRAITH_FAIL: -5}
del corpo ="{
‘richiesta’: {
‘travis_event_type’: ‘$ TRAVIS_EVENT_TYPE’,
‘travis_pull_request’: ‘$ TRAVIS_PULL_REQUEST’,
‘travis_repo_slug’: ‘$ TRAVIS_PULL_REQUEST_SLUG’,
‘travis_branch’: ‘$ TRAVIS_PULL_REQUEST_BRANCH’,
‘wraithSlug’: $ WRAITH_SLUG,
‘wraithFail’: $ WRAITH_FAIL,
}
}"
eco "Attivazione della generazione del ramo $ TRAVIS_PULL_REQUEST_SLUG
$ TRAVIS_PULL_REQUEST_BRANCH “su Travis."
output = $ (arricciatura -sw "% {} HTTP_CODE" -X POST \
-H "Tipo di contenuto: application / json" \
-H "Accetta: application / json" \
-H "Travis-API-Version: 3" \
-d "$ {// corpo \ ‘/ \"}" \
‘Http://wraith.themeisle.com’)
HTTP_CODE ="$ {Output: $ {# output}} -3"
if [$ {# output} -eq 3]; poi
del corpo =""
altro
del corpo ="$ {Output: 0: $ {# output}} -3"
fi

if [$ http_code! = 200]; poi
eco "$ uscita";
uscita 1
altro
eco "$ uscita";
uscita 0
fi

In breve, questo script crea un payload JSON contenente le variabili di ambiente Travis predefinite e quelle impostate dall’utente. Inoltre, legge Packages.json e ottiene la lumaca tema.

La seconda parte dello script invia una richiesta POST tramite "arricciare" a Pirate Wraith e analizza la risposta al fine di recuperare il codice di stato HTTP / 1.1 della risposta.

Usiamo il codice di stato per "fallire" o "passaggio" la build. L’API Pirate Wraith restituisce codici HTTP / 1.1 validi per ogni richiesta che elabora.

  • Restituirà il codice 200 per i test completi e superati.
  • Per tutto il resto, la compilazione fallirà con un codice di uscita 1 (uscita 1)

Potresti chiederti cosa sia il confronto tra Wraith. La risposta è semplice; confronta la distribuzione dell’inquilino dell’attuale richiesta pull da Pirate Bootstrap con la demo del tema target.

Per una migliore comprensione del ciclo di vita di GitHub – Travis – Pirate Bootstrap – Pirate Wraith, ecco un diagramma che illustra il flusso di lavoro di questi servizi:

Flusso di lavoro Pirate Bootstrap / Pirate Wraith

Come potete vedere, GitHub avvisa entrambi Bootstrap pirata e Travis su una nuova richiesta pull. Bootstrap inizia a distribuire un inquilino, chiede Travis Pirate Wraith per iniziare i test.

Pirate Wraith confronta la versione del Locatario della Demo con la ThemeIsle Demo e restituisce i risultati a Travis, in modo che possa passaggio o fallire la build.

allentato

Oltre al supporto Travis, Pirate Wraith ha un endpoint per l’integrazione con Slack.

Al termine di una compilazione di Travis (pass o fail), viene generato un report all’interno del canale #eyepatch, contenente un collegamento alla galleria generata e un riepilogo delle differenze rilevate.

Sono inoltre integrati alcuni utili comandi di Slack che puoi utilizzare in qualsiasi canale (Nota: l’API Pirate Wraith risponderà in quel canale con una risposta pubblica, quindi ti consigliamo di utilizzare i comandi in auto chat). Ecco i comandi per Slack:

Ripristino degli scatti di base della cronologia di un tema

/ wraith-history [tema-lumaca]

Esempio:

/ storia di wraith zerif-lite |

Confronto con gli scatti storici di un tema

/ wraith-latest [tema-lumaca] [url]

Esempio:

/ wraith-latest zerif-lite http: //forks.url/pb/zerif-lite |

Questo comando utilizza la lumaca fornita per confrontare l’URL specificato con la cronologia di quella lumaca.

Confronto tra due URL

/ wraith-compare [url] vs [url]

Esempio:

/ wraith-compare http://url.one vs http: //url.two 

Pirate Wraith – consigli & trucchi e altre informazioni utili

Ripristino degli scatti di base della cronologia di un tema

wraith reset history [tema-lumaca]

Questo comando reimposta la cronologia per la lumaca data.

Confronto con gli scatti storici di un tema

wraith check latest [theme-slug] [url]

Questo comando utilizza la lumaca fornita per confrontare l’URL specificato con la cronologia di quella lumaca.

Confronto tra due URL

wraith compare urls [url-one] [url-two]

Visualizzazione dei registri

Il comando è mostra registri. Questo comando è utile se è necessario controllare i file di registro. Funziona allo stesso modo di Pirate Bootstrap.

La tua opinione?

Questo riassume praticamente i nostri due nuovi servizi e il modo in cui possono essere utilizzati per automatizzare la distribuzione dei temi di WordPress.

Abbiamo creato sia Pirate Bootstrap che Pirate Wraith per soddisfare le nostre esigenze, ma crediamo che questi concetti possano essere utili anche a chiunque lavori su progetti di sviluppo simili. Soprattutto se stai costruendo prodotti derivati ​​(come i temi WordPress pro e lite nel nostro caso) e vuoi controllare che tipo di impatto hanno specifiche modifiche del codice sui loro aspetti.

La cosa con i temi WordPress è che le basi di codice della maggior parte dei temi moderni tendono a crescere abbastanza rapidamente e alcuni elementi specifici di tali basi di codice possono avere un impatto imprevedibile sull’aspetto di altri elementi del tema. Cercare di catturare tutto ciò manualmente – semplicemente guardando le cose attraverso i tuoi occhi umani – può essere davvero impegnativo, quindi è sempre di grande aiuto introdurre una sorta di algoritmo / automazione nel mix.

Ma tu cosa ne pensi Vedi il valore di strumenti come questi anche per altri progetti?

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map