Cerca

All’interno nella nostra Dev House: Come gestiamo la distribuzione automatica dei temi WordPress LITE e PRO

 

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”.

Come gestiamo la distribuzione automatica dei temi per LITE e PRO #WordPress #Themes

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ì:

Distribuzione automatica dei temi per temi WordPress LITE e PRO

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 pulluso di “ssh_url” in tenant/content/themes/.
  • Nel caso in cui non è una singola distribuzione, facciamo un git pull in tmp/, correre grunt generate e poi copiare le cartelle risultanti in tenant/content/themes/.

Il  grunt generatecompito è 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 generateper 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:

Flusso di lavoro Pirate Bootstrap / Pirate Wraith

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?

Open

info.ibdi.it@gmail.com

Close