Inside the Dev House: Comment nous gérons le déploiement automatique des thèmes pour les thèmes WordPress LITE et PRO

Inside the Dev House: Comment nous gérons le déploiement automatique des thèmes pour les thèmes WordPress LITE et PRO

Inside the Dev House: Comment nous gérons le déploiement automatique des thèmes pour les thèmes WordPress LITE et PRO
СОДЕРЖАНИЕ
02 июня 2020

Comme vous pouvez l’imaginer, le développement de thèmes est quelque chose que nous faisons beaucoup ici dans l’entreprise. Avec environ 4 à 5 nouveaux projets thématiques en cours à tout moment et 80 thèmes en notre annuaire au total (ce qui signifie une maintenance active et un développement ultérieur de ceux-ci également), nous avons les mains plutôt pleines.


Dans un cadre comme celui-ci, une optimisation et même une automatisation, dans la mesure du possible, sont essentielles.

Donc, aujourd’hui, nous voulons vous inviter à travers notre porte de maison de développement à ThemeIsle, pour ainsi dire, et vous montrer deux pièces spécifiques de notre puzzle de développement de thème.

Je ne cacherai pas que ce type de message est une expérience. Si vous l’appréciez, nous nous assurerons de faire ressortir plus de choses comme ça à l’avenir.

Plus précisément, le sujet d’aujourd’hui est quelque chose qui peut être appelé, "déploiement automatique et architecture de régression visuelle pour le développement de thèmes WordPress."

Attendez, quel est le déploiement automatique des thèmes?

Si vous ne parlez pas développeur, cela signifie en anglais que vous pouvez développer des thèmes pour WordPress, les déployer sur un serveur, puis comparer visuellement les différences par rapport à une ligne de base prédéfinie sans avoir à faire quoi que ce soit manuellement.

Tout se passe automatiquement, ou plutôt, "automagiquement."

Comment cela marche-t-il?

Nous avons développé deux services pour prendre en charge ce déploiement de thème automatique: "Pirate Bootstrap" et "Pirate Wraith."

Le premier, Pirate Bootstrap, peut être activé via Webhooks de GitHub.

Sur Pull Request, il déploie une nouvelle instance WordPress, en utilisant un thème donné à partir d’un référentiel défini + tous les packages et les paramètres de base de données extraits de la démo par défaut du thème sur ThemeIsle.

Ce dernier, Pirate Wraith, fait un test de régression visuelle (alias comparer les images de deux sources). Le test vérifie visuellement le nouveau déploiement du thème par rapport à la démo de ThemeIsle, puis génère un rapport. Sur la base de ce rapport, vous pouvez rapidement voir si les modifications récentes ont eu un impact sur l’apparence du thème.

En d’autres termes, chaque fois que vous travaillez sur un thème et que vous voulez vous assurer que vos dernières modifications de code n’ont pas gâché la conception du thème, vous pouvez utiliser Pirate Wraith pour gérer la tâche sur le pilote automatique..

Expliquons chaque service plus en détail:

Pirate Bootstrap – déploie une nouvelle instance de WordPress en utilisant un thème défini

Pirate Bootstrap est hébergé sur forks.themeisle.com

Pirate Bootstrap est construit sur WP-CLI et a des méthodes pour générer des déploiements WordPress complets basé sur les packages de thèmes et les dépendances de ThemeIsle.

Les éléments:

Webhooks GitHub

Les webhooks sont utilisés pour appeler l’API de Pirate Bootstrap sur les requêtes Pull (ouvertes ou synchronisées) en envoyant une charge utile JSON à http://forks.themeisle.com

Cela lance le workflow de déploiement sur forks.themeisle.com. Ainsi:

Déploiement automatique des thèmes pour les thèmes WordPress LITE et PRO

Exemple d’une charge utile GitHub Pull Request:

{
"action": "ouvert",
"nombre": 1,
"pull_request": {

"tête": {
"étiquette": "preda-bogdan: production",
"ref": "production",
"sha": "****",

"repo": {
"id": 82166596,
"Nom": "zerif-lite",
"nom complet": "preda-bogdan / zerif-lite",
"propriétaire": {
"s’identifier": "preda-bogdan",

},
"privé": faux,

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

}
},

}
}

  • Nous utilisons le "sha" pour vérifier s’il s’agit d’une demande valide et si nous sommes autorisés à traiter la charge utile.
  • Nous utilisons "s’identifier", "Nom" et "ref" pour générer un locataire s’il n’existe pas.

La structure du fichier

La structure de fichiers sur le serveur est définie de sorte que nous stockons chaque locataire dans son propre dossier public et ayons une installation principale de WordPress que nous utilisons pour référencer avec un lien symbolique pour chaque locataire.

La structure du fichier locataire est la suivante:

locataire/
| _ wp / / ** symlink core install de WordPress
| _ contents / / ** dossier de contenu du locataire pour WordPress
| | _ themes / / ** dossier de thème locataire pour WordPress
| | _ plugins / / ** dossier des plugins locataires pour WordPress
| _ .htaccess / ** .htaccess généré automatiquement pour le locataire
| _ vhost.conf / ** fichier de configuration d’alias pour apache
| _ wp-config.php / ** fichier de configuration généré automatiquement pour le locataire

Le dossier wp / fait référence à l’installation principale de WordPress, qui est partagée par tous les locataires. De cette façon, nous pouvons avoir une seule installation de WordPress et plusieurs instances isolées de sites WordPress, chacune avec des paramètres, des fichiers et des ressources encapsulés.

Les fichiers core et tenant wp-config.php

Exemple de base WordPress wp-config.php:

/ ** Chemin absolu vers le répertoire WordPress. * /
require_once ($ _SERVER [‘CONTEXT_DOCUMENT_ROOT’]. ‘wp-config.php’);

/ ** Configure les fichiers WordPress vars et les fichiers inclus. * /
require_once (ABSPATH. ‘wp-settings.php’);

Exemple de locataire wp-config.php:

(Les valeurs contenues à l’intérieur des accolades doubles sont remplacées automatiquement lors de la création du locataire.)

/ ** AJOUTÉ PAR L’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’);

si (! défini (‘ABSPATH’))
define (‘ABSPATH’, dirname (__ FILE__). ‘/ wp’);

Après la création du locataire, nous interrogeons un point de terminaison pour récupérer les packages nécessaires au déploiement de thèmes (plugins, thèmes enfants, base de données). Les packages sont mis en cache / stockés dans un dossier de dissimulation sur le serveur et sont actualisés toutes les six heures.

L’étape suivante consiste à vérifier si le thème que nous voulons déployer est un déploiement unique ou doit générer des thèmes supplémentaires à partir du thème de base.

  • S’il s’agit d’un déploiement unique, nous faisons juste un pull git en utilisant "ssh_url" en locataire / contenu / thèmes /.
  • Dans le cas où ce n’est pas un déploiement unique, nous faisons un pull git dans tmp /, exécutons grunt generate et copions ensuite les dossiers résultants dans tenant / content / themes /.

La tâche de génération de grognement est une norme pour nous lorsque nous travaillons avec des thèmes qui ont plusieurs versions (généralement "léger" et "pro") tout en utilisant la même base de code (référentiel). Par exemple, si nous exécutons grunt generate pour le référentiel hestia-pro, nous obtiendrons également la version lite automatiquement.

Après avoir manipulé ce qui précède, nous utilisons WP-CLI pour installer tous les packages requis (plugins et / ou thèmes enfants) et importer le vidage de la base de données depuis demo.themeisle.com.

Les dernières étapes consistent à vider les règles de réécriture .htaccess, à mettre à jour "URL du site" et "maison" avec l’URL du locataire et l’URL de WordPress Core, mettez à jour les liens pour les éléments de menu et les publications, puis rechargez enfin apache.

Nous envoyons ensuite à l’utilisateur un e-mail avec son URL fourchue pour la demande Pull et le journal généré pendant le déploiement. (Chaque locataire généré suit ce modèle d’URL général: http://forks.themeisle.com/github-login/theme-slug/branch/)

Pirate Bootstrap – conseils & astuces et autres informations utiles

Lorsque vous accédez à forks.themeisle.com, vous pouvez accéder à une interface de type terminal en appuyant sur la touche "~" (touche tilde), puis exécutez un tas de commandes utiles à partir de là. Les plus pertinents sont:

Réinitialisation d’un déploiement de locataire

La commande est pirate reset tenant [tenant] (* theme-slug) |

Exemple:

pirate réinitialise le locataire preda-bogdan / zerif-lite / development |  

Ou:

pirate réinitialise le locataire preda-bogdan / hestia / development hestia-pro |

La commande reset réinitialise le locataire à son état de déploiement d’origine (réinitialisation de la base de données, réinstallation des plug-ins et / ou des thèmes enfants).

Affichage des journaux

La commande est afficher les journaux. Cette commande est utile si vous devez vérifier les fichiers journaux après un déploiement et que vous n’avez pas encore reçu d’e-mail ou que vous devez déboguer.

Remarque: le fichier journal est pivoté si la taille du fichier dépasse 9 000 octets. Par conséquent, si vous ne trouvez pas ce que vous recherchez, vous devrez peut-être vérifier l’archive du journal directement sur le serveur..

Pirate Wraith – compare visuellement deux versions d’un thème

Pirate Wraith est hébergé sur wraith.themeisle.com

Pirate Wraith est construit sur Spectre et dispose de points de terminaison pour interagir avec les demandes Slack, Travis et AJAX afin de tirer parti des capacités de Wraith et de générer des tests et des rapports de régression visuelle.

Travis

Pirate Wraith expose un point de terminaison sur wraith.themeisle.com qui écoute les demandes d’une build Travis, et "échoue" ou "passe" la construction en fonction des résultats du test de régression visuelle.

À l’intérieur du fichier .travis.yml, nous avons ajouté une nouvelle matrice qui définit une nouvelle construction par-dessus celles existantes. Cela définit les autorisations pour exécuter un script bash à l’intérieur du projet, puis l’exécute.

Le fichier Travis YML:

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

Tu peux voir ça "installer" et "before_script" sont laissés en blanc. Ceci est exprès, afin que la génération n’hérite pas des actions des générations définies précédemment. Nous voulons simplement exécuter le script bash (script: ./wraith.sh) sur cette version.

A noter également; nous définissons une variable d’environnement appelée WRAITH_FAIL. Cette valeur est utilisée pour indiquer à Pirate Wraith quelle est la différence de centile maximale autorisée pour réussir un test..

Le script Bash:

#! / bin / bash
WRAITH_SLUG = $ (node ​​-pe "require (‘./ package.json’). wraithSlug")
WRAITH_FAIL = $ {WRAITH_FAIL: -5}
corps ="{
‘demande’: {
‘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,
}
}"
écho "Déclenchement de la construction de la branche $ TRAVIS_PULL_REQUEST_SLUG
$ TRAVIS_PULL_REQUEST_BRANCH ‘sur Travis."
sortie = $ (curl -sw "% {http_code}" -X POST \
-H "Type de contenu: application / json" \
-H "Accepter: application / json" \
-H "Travis-API-Version: 3" \
-ré "$ {body // \ ‘/ \"}" \
«http://wraith.themeisle.com»)
http_code ="$ {sortie: $ {# sortie} -3}"
if [$ {# output} -eq 3]; puis
corps =""
autre
corps ="$ {sortie: 0: $ {# sortie} -3}"
Fi

si [$ http_code! = 200]; puis
écho "$ sortie";
sortie 1
autre
écho "$ sortie";
sortie 0
Fi

En bref, ce script crée une charge utile JSON contenant les variables d’environnement Travis par défaut et celles définies par l’utilisateur. En outre, il lit packages.json et obtient le slug de thème.

La deuxième partie du script effectue une requête POST via "boucle" à Pirate Wraith et analyse la réponse afin de récupérer le code d’état HTTP / 1.1 de la réponse.

Nous utilisons le code d’état pour "échouer" ou "passer" la construction. L’API Pirate Wraith renvoie des codes HTTP / 1.1 valides pour chaque demande qu’elle traite.

  • Il renverra le code 200 pour des tests complets et réussis.
  • Pour tout le reste, la construction échouera avec un code de sortie de 1 (sortie 1)

Vous vous demandez peut-être ce que Wraith compare. La réponse est simple; il compare le déploiement du locataire de la demande de tirage actuelle de Pirate Bootstrap avec la démo du thème cible.

Pour une meilleure compréhension du cycle de vie GitHub – Travis – Pirate Bootstrap – Pirate Wraith, voici un schéma illustrant le workflow de ces services:

Flux de travail de Pirate Bootstrap / Pirate Wraith

Comme vous pouvez le voir, GitHub informe les deux Pirate Bootstrap et Travis à propos d’une nouvelle demande Pull. Bootstrap commence à déployer un locataire, demande Travis Pirate Wraith pour commencer les tests.

Pirate Wraith compare la version Tenant de la démo avec la version ThemeIsle Démo et renvoie les résultats à Travis, pour qu’il puisse passer ou échouer la construction.

Mou

En plus de la prise en charge de Travis, Pirate Wraith a un point d’extrémité pour l’intégration avec Slack.

Une fois la construction de Travis terminée (réussite ou échec), un rapport est généré à l’intérieur du canal #eyepatch, contenant un lien vers la galerie générée et un résumé des différences trouvées..

Quelques commandes Slack utiles que vous pouvez utiliser dans n’importe quel canal sont également intégrées (Remarque: l’API Pirate Wraith répondra dans ce canal avec une réponse publique, nous vous recommandons donc d’utiliser les commandes dans le chat automatique). Voici les commandes pour Slack:

Réinitialisation des prises de vue de base de l’historique d’un thème

/ wraith-history [thème-slug]

Exemple:

/ histoire-de-zerif-lite |

Comparaison avec les prises de vue historiques d’un thème

/ wraith-latest [thème-slug] [url]

Exemple:

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

Cette commande utilise le slug fourni pour comparer l’URL donnée avec l’historique de ce slug.

Comparaison de deux URL

/ wraith-compare [url] vs [url]

Exemple:

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

Pirate Wraith – conseils & astuces et autres informations utiles

Réinitialisation des prises de vue de base de l’historique d’un thème

wraith reset history [thème-slug]

Cette commande réinitialise l’historique du slug donné.

Comparaison avec les prises de vue historiques d’un thème

vérifier avec le dernier [thème-slug] [url]

Cette commande utilise le slug fourni pour comparer l’URL donnée avec l’historique de ce slug.

Comparaison de deux URL

comparer les URL [url-one] [url-two]

Affichage des journaux

La commande est afficher les journaux. Cette commande est utile si vous devez vérifier les fichiers journaux. Cela fonctionne de la même manière que dans Pirate Bootstrap.

Votre avis?

Cela résume à peu près nos deux nouveaux services et comment ils peuvent être utilisés pour automatiser le déploiement de thèmes WordPress.

Nous avons créé Pirate Bootstrap et Pirate Wraith pour répondre à nos propres besoins, mais nous pensons que ces concepts peuvent être tout aussi utiles à tous ceux qui travaillent sur des projets de développement similaires. Surtout si vous créez des produits dérivés (comme les thèmes WordPress pro et lite dans notre cas) et que vous souhaitez vérifier quel type d’impact des changements de code spécifiques ont sur leurs apparences.

Le problème avec les thèmes WordPress est que les bases de code de la plupart des thèmes modernes ont tendance à croître assez rapidement, et certains éléments spécifiques de ces bases de code peuvent avoir un impact imprévisible sur l’apparence d’autres éléments du thème. Essayer de saisir tout cela manuellement – juste en regardant les choses à travers vos propres yeux humains – peut être très difficile, donc c’est toujours une aide énorme d’introduire une forme d’algorithme / d’automatisation dans le mix.

Mais qu’est ce que tu penses? Voyez-vous aussi la valeur d’outils comme ceux-ci pour d’autres projets?

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Это интересно
    Adblock
    detector