In un ambiente come questo, alcuni l’ottimizzazione e persino l’automazione, ove possibile, è la chiave.
Quindi oggi, vogliamo invitarti attraverso la nostra porta di casa di sviluppo su 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 “architettura di distribuzione automatica e regressione visiva per lo sviluppo del tema di 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: “Pirate Bootstrap” e “Pirate Wraith”.
Il primo, Pirate Bootstrap, può essere attivato tramite Webhooks da GitHub.
Su richiesta pull, distribuisce una nuova istanza di WordPress, usando 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 visivamente la nuova distribuzione del tema rispetto alla demo di ThemeIsle e quindi genera un rapporto. Sulla base di quel 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 la progettazione 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 è basato su WP-CLI e ha metodi per generare distribuzioni complete di WordPress basate su pacchetti di temi e dipendenze di ThemeIsle.
Gli elementi:
GitHub Webhooks
I webhook vengono utilizzati per chiamare l’API di Pirate Bootstrap su (aperto o sincronizzato) richieste pull inviando un payload JSON a http://forks.themeisle.com
Questo avvia il flusso di lavoro di distribuzione su forks.themeisle.com
. Così:
Esempio di payload della richiesta pull di GitHub:
{
"action": "opened",
"number": 1,
"pull_request": {
...
"head": {
"label": "preda-bogdan:production",
"ref": "production",
"sha": "****",
...
"repo": {
"id": 82166596,
"name": "zerif-lite",
"full_name": "preda-bogdan/zerif-lite",
"owner": {
"login": "preda-bogdan",
...
},
"private": false,
...
"git_url": "git://github.com/preda-bogdan/zerif-lite.git",
"ssh_url": "git@github.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",
...
}
},
...
}
}
- Usiamo il tasto “sha” per verificare se si tratta di una richiesta valida e se è consentito elaborare il payload.
- Usiamo “login”, “name” e “ref” per generare un inquilino se non esiste.
La struttura dei file
La struttura dei file sul server è impostata in modo tale da archiviare ciascun tenant nella sua cartella pubblica e disporre di un’installazione principale di WordPress che utilizziamo per fare riferimento a un collegamento simbolico per ciascun tenant.
La struttura del file tenant è la seguente:
tenant/
|_ wp/ /** symlink core install of WordPress
|_ contents/ /** tenant content folder for WordPress
| |_ themes/ /** tenant theme folder for WordPress
| |_ plugins/ /** tenant plugins folder for WordPress
|_ .htaccess /** auto-generated .htaccess for tenant
|_ vhost.conf /** alias config file for apache
|_ wp-config.php /** auto-generated config file for tenant
La wp/
cartella fa riferimento all’installazione principale di WordPress, che è condivisa da tutti i tenant. In questo modo, possiamo avere un’unica 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:
/** Absolute path to the WordPress directory. */
require_once( $_SERVER['CONTEXT_DOCUMENT_ROOT'].'wp-config.php');
/** Sets up WordPress vars and included files. */
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.)
/** ADDED BY BOOTSTRAP API */
{{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 ( ! defined( '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
uso di “ssh_url” intenant/content/themes/
. - Nel caso in cui non è una singola distribuzione, facciamo un
git pull
intmp/
, correregrunt generate
e poi copiare le cartelle risultanti intenant/content/themes/
.
Il grunt generate
compito è uno standard per noi quando si lavora con temi che hanno più versioni (di solito “lite” e “pro”) mentre si utilizza lo stesso codebase (repository). Ad esempio, se corriamo 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 “siteurl” e “home” con l’URL del tenant e l’URL per WordPress Core, aggiornare i collegamenti per le voci di menu e i post, quindi ricaricare finalmente apache.
Quindi inviamo all’utente un’e-mail con l’URL biforcato per la richiesta pull e il registro generato durante la distribuzione. (Ogni inquilino generato segue questo modello generale URL: http://forks.themeisle.com/github-login/theme-slug/branch/
)
Pirate Bootstrap: suggerimenti e 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 insieme di comandi utili da lì. I più rilevanti sono:
Ripristino di una distribuzione di titolari
Il comando è pirate reset tenant [tenant] (*theme-slug) |
Esempio:
pirate reset tenant preda-bogdan/zerif-lite/development |
O:
pirate reset tenant 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 è show logs
. 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 presso wraith.themeisle.com
Pirate Wraith si basa su Wraith 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 “fallisce” o “passa” 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:
matrix:
include:
- php: "7.0"
before_install: chmod +x wraith.sh
install:
before_script:
env: TEST_SUITE=Wraith_Visual_Regression_Testing WRAITH_FAIL=5
script: ./wraith.sh
Puoi vedere che “installa” e “before_script” sono 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=$(node -pe "require('./package.json').wraithSlug")
WRAITH_FAIL=${WRAITH_FAIL:-5}
body="{
'request': {
'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,
}
}"
echo "Triggering build of $TRAVIS_PULL_REQUEST_SLUG branch
$TRAVIS_PULL_REQUEST_BRANCH' on Travis."
output=$(curl -sw "%{http_code}" -X POST \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Travis-API-Version: 3" \
-d "${body//\'/\"}" \
'http://wraith.themeisle.com')
http_code="${output:${#output}-3}"
if [ ${#output} -eq 3 ]; then
body=""
else
body="${output:0:${#output}-3}"
fi
if [ $http_code != 200 ]; then
echo "$output";
exit 1
else
echo "$output";
exit 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 fa una richiesta POST tramite “curl” 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 “passare” 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:
Come puoi vedere, GitHub notifica a Pirate Bootstrap e Travis una nuova richiesta pull. Bootstrap inizia a distribuire un inquilino, Travis chiede a Pirate Wraith di iniziare i test.
Pirate Wraith confronta la versione del Locatario della Demo con la Demo ThemeIsle e restituisce i risultati a Travis , in modo che possa passare 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 Slack che è possibile utilizzare in qualsiasi canale (Nota: l’API Pirate Wraith risponderà in quel canale con una risposta pubblica, quindi si consiglia di utilizzare i comandi in auto chat). Ecco i comandi per Slack:
Ripristino degli scatti di base della cronologia di un tema
/wraith-history [theme-slug]
Esempio:
/wraith-history zerif-lite |
Confronto con gli scatti della storia di un tema
/wraith-latest [theme-slug] [url]
Esempio:
/wraith-latest zerif-lite http://forks.url/pb/zerif-lite |
Questo comando utilizza lo slug fornito per confrontare l’URL specificato con la cronologia dello slug.
Confronto tra due URL
/wraith-compare [url] vs [url]
Esempio:
/wraith-compare http://url.one vs http://url.two
Pirate Wraith: consigli e suggerimenti, e altre informazioni utili
Ripristino degli scatti di base della cronologia di un tema
wraith reset history [theme-slug]
Questo comando reimposta la cronologia per la lumaca data.
Confronto con gli scatti della storia di un tema
wraith check latest [theme-slug] [url]
Questo comando utilizza lo slug fornito per confrontare l’URL specificato con la cronologia dello slug.
Confronto tra due URL
wraith compare urls [url-one] [url-two]
Visualizzazione dei registri
Il comando è show logs
. Questo comando è utile se è necessario controllare i file di registro. Funziona allo stesso modo di Pirate Bootstrap.
Il tuo introito?
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 altrettanto utili per 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 di 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?