Déploiements modernes pour vos sites WordPress

Si vous êtes comme moi, votre première expérience de transmission de fichiers sur un serveur Web s'est faite via un gestionnaire de fichiers Web tel que cPanel ou un client FTP (File Transfer Protocol) tel que Transmit ou Filezilla. Connectez-vous au serveur, faites glisser votre ou vos fichiers et attendez que le transfert soit terminé.

Facile, non ?

Cependant, dès que j'ai commencé à travailler avec quelque chose de plus complexe que des fichiers HTML statiques, le déploiement de mon code est devenu beaucoup plus complexe : que se passe-t-il si je manque un fichier requis par d'autres, ou un point-virgule dans une inclusion globale et qu'il affiche un écran blanc sur le tout le site ? Que se passe-t-il si une étape cruciale est manquée au cours du processus ?

Ces problèmes de "codage de cow-boy" ne font qu'empirer à mesure que de plus en plus de personnes, d'environnements et de dépendances sont impliqués. En conséquence, il devient de plus en plus difficile de continuer à progresser tout en jonglant avec toutes ces pièces mobiles. Pire encore, la publication de code devient un gros problème et une source constante d'anxiété.

À mesure que nos applications, nos sites et nos magasins se modernisent, nous devrions également moderniser nos déploiements. Du contrôle de version à la livraison continue, un processus de publication moderne peut soulager l'anxiété liée aux déploiements.

Suivi des modifications avec le contrôle de version

La première étape pour s'éloigner des mises à jour ad hoc et du codage cowboy consiste à mettre votre site sous contrôle de version, à l'aide d'un outil comme Git.

L'utilisation du contrôle de version signifie que vous pourrez voir ce qui a changé, qui a effectué les modifications et même travailler sur plusieurs ensembles de modifications en même temps en utilisant des branches. Par conséquent, le travail n'est pas écrasé et tout conflit entre les fichiers est clairement mis en évidence.

Si vous n'avez jamais travaillé avec Git auparavant, n'ayez crainte : nous avons rédigé à la fois une introduction à Git et un article sur les workflows Git plus avancés.

Décider quoi suivre

Au fur et à mesure que nous mettons notre site sous contrôle de version, ce dont nous ne gardons pas trace est presque aussi important que ce que nous faisons :

De manière générale, le contrôle de version sert à suivre le code source, et non les actifs générés par les outils ou les processus . Cela inclut des éléments tels que CSS et JavaScript concaténés/minifiés, des dépendances externes, etc. Collectivement, nous appelons ces éléments des artefacts .

Par exemple, si vous utilisez un préprocesseur CSS comme Sass, les fichiers CSS générés ne doivent pas être suivis sous contrôle de version. Non seulement ils sont facilement reproductibles, mais ils sont difficiles à lire et constituent une source courante de conflits de fusion lorsque plusieurs développeurs sont impliqués.

En ce qui concerne les dépendances (bibliothèques, plugins WordPress, etc.), profitez d'outils comme Composer et WPackagist plutôt que de regrouper du code dont vous n'êtes pas responsable dans votre référentiel.

De plus, un référentiel Git ne doit jamais contenir d'éléments tels que des mots de passe, des clés SSH privées ou toute autre information confidentielle qui serait considérée comme secrète , car chaque développeur disposant d'une copie du référentiel aurait alors ces informations sensibles sur son ordinateur.

Structurer votre référentiel

Lors de la configuration d'un référentiel Git pour un site WordPress ou WooCommerce, il est généralement préférable de traiter wp-content/ comme la racine du référentiel, car vous ne toucherez généralement pas aux fichiers situés au-dessus de ce répertoire.

Les plugins et les thèmes que votre site utilise mais dont vous ne gérez pas le code doivent ensuite être chargés via Composer, car ce sont des dépendances externes. De même, les fichiers CSS et JavaScript traités doivent être exclus via le fichier .gitignore, car ces artefacts seront créés pour nous dans le cadre de notre processus de publication.

Nous avons un modèle de référentiel gratuit disponible sur GitHub pour vous aider à démarrer.

Une introduction au CI/CD

Lorsqu'il s'agit de déployer un logiciel, il y a deux termes importants à comprendre : l'intégration continue (CI) et la livraison continue (CD).

Ces deux termes sont étroitement liés, à tel point qu'ils sont souvent appelés collectivement « CI/CD », et le chemin par lequel nos changements s'écoulent devient ainsi le « pipeline CI/CD ». Ce pipeline prend généralement la forme suivante :

1. Construisez la version : installez les dépendances (Composer, npm, etc.), puis créez des artefacts (Webpack, Grunt, Sass, etc.)
2. Testez la construction : exécutez des tests unitaires, vérifiez les normes de codage, effectuez une analyse de code statique, etc.
3. Déployer la version dans un ou plusieurs environnements

L'intégration continue est le processus de test continu de notre code pour s'assurer que les modifications ne brisent pas les fonctionnalités existantes, afin que nos nouvelles modifications s'intègrent proprement à la base de code existante. Chaque fois que de nouveaux changements sont poussés, des vérifications sont effectuées pour s'assurer que nous ne « cassons pas la construction ».

Pour que l'intégration continue soit utile, ces vérifications doivent être automatisées. Par exemple, si vous avez une suite de tests unitaires, vous pouvez choisir d'exécuter cette suite de tests à chaque fois qu'une nouvelle demande d'extraction est ouverte, vous alertant d'éventuelles ruptures avant que le code n'arrive en production.

L'intégration continue ne se limite cependant pas aux tests unitaires, car il existe un certain nombre de vérifications "sans code" qui peuvent être exécutées automatiquement sur votre code, notamment :

• Vérification des normes de codage (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Analyse de code statique (PHPStan, Psalm)

L'exécution automatique de ces vérifications à chaque poussée garantit également que tout le code est exécuté par les mêmes vérifications, empêchant le code qui ne passe pas d'être publié.

La livraison continue , quant à elle, est l'idée que nous devrions être capables de « livrer » (déployer) notre code à tout moment. Pour ce faire, nous devons disposer d'un processus de déploiement scripté qui, d'un simple clic, déplacera de manière transparente notre code en production.

Avoir vos déploiements scriptés signifie que vous pouvez déployer à la fois régulièrement et de manière cohérente ; chaque déploiement doit fonctionner de la même manière que le précédent. En conséquence, votre équipe peut se déployer plus régulièrement avec un niveau de confiance plus élevé et moins de soucis que quelqu'un ait raté une étape en cours de route. Pour certaines équipes, il n'est pas rare de se déployer des dizaines (voire des centaines) de fois par jour !

Selon votre site, vous voudrez peut-être même regarder dans "l'autre CD", le déploiement continu ; c'est très similaire à la livraison continue, mais dans ce modèle, chaque poussée vers une succursale est déployée automatiquement. Cela peut être extrêmement puissant lors de l'utilisation d'un schéma de contrôle de version ramifié (tel que Github Flow), mais peut être indésirable si vous devez planifier des fenêtres de publication ou effectuer tout le travail dans la branche principale.

Déploiement d'un site WordPress ou WooCommerce avec CI/CD

Maintenant que nous maîtrisons la terminologie de base, examinons le déploiement d'un site WordPress ou WooCommerce typique :

Pour cet exercice, nous utiliserons Branch, un outil CI/CD conçu autour des besoins des développeurs WordPress des mêmes personnes derrière WP Pusher. Mieux encore, Branch dispose d'un support intégré pour le déploiement sur Nexcess !

Pour commencer, inscrivez-vous à Branch en connectant votre compte GitHub, GitLab ou Bitbucket, puis en créant votre premier site.

Ensuite, nous voudrons configurer toutes les étapes nécessaires pour construire notre site. Branch propose un certain nombre de "recettes" pour les actions courantes (installation de dépendances Composer, exécution de Webpack, etc.), mais nous donne également la possibilité d'ajouter un nombre quelconque d'étapes personnalisées.

Une fois que nous avons décrit les étapes nécessaires à la construction de notre site, nous pouvons passer à l'étape suivante de notre pipeline : les tests.

Si vous disposez déjà d'une suite de tests automatisés pour votre site, vous pouvez simplement dire à Branch d'exécuter les commandes nécessaires. Même si vous n'avez pas encore de tests, Branch facilite l'ajout de peluches, de normes de codage et de vérifications de compatibilité.

Maintenant que nous avons installé nos dépendances, tout construit et réussi nos tests, il est temps de mettre notre code en production !

Branch contient des recettes pour le déploiement sur Nexcess (ainsi que sur d'autres principaux fournisseurs d'hébergement), et la connexion des deux plates-formes est indolore :

1. Sélectionnez votre site dans le tableau de bord Branch, cliquez sur "Paramètres", puis récupérez la clé SSH publique de votre site Branch
2. Ajouter cette clé publique à la liste des clés du portail Nexcess

Une fois que Branch est en mesure de communiquer avec votre site Nexcess, nous pouvons sélectionner la recette de déploiement « Nexcess » et renseigner quelques détails :

1. Le nom d'hôte et le nom d'utilisateur du site (disponibles via le portail Nexcess sur l'écran "Accès" de votre site)
2. La racine Web sur laquelle nous déployons. Si notre référentiel git est destiné à servir de répertoire wp-content/, cette valeur doit être « public_html/wp-content ».
3. Les fichiers que nous souhaitons déployer (généralement la valeur par défaut, "*", est suffisante)
4. La branche git à déployer dans cet environnement

Le paramètre "Git branch" est particulièrement important, car il vous permet de spécifier différents déploiements pour différentes branches. Par exemple, vous pouvez avoir une branche « staging » qui se déploie dans votre environnement de staging, vous permettant de tester les modifications avant de les mettre en ligne.

Il convient de noter que Branch utilise le modèle de déploiement continu par défaut, où le pipeline s'exécute à chaque poussée vers la branche donnée. Si vous préférez plutôt un modèle de livraison continue (où certaines actions manuelles doivent être entreprises), vous pouvez envisager de maintenir une branche « production » qui n'est fusionnée que lorsque vous êtes prêt à publier.

À ce stade, Branch doit être configuré pour créer et déployer votre référentiel git sur Nexcess ! Vous pouvez déclencher votre premier déploiement soit en cliquant sur le bouton "Exécuter le déploiement" sur la page "Pipelines" de votre site, soit en poussant vers votre référentiel Git.

Personnalisation de votre processus de publication

L'une des fonctionnalités vraiment intéressantes de Branch est la possibilité de configurer des étapes supplémentaires après un déploiement réussi, comme l'effacement automatique du cache d'objets de votre site après un déploiement. Cela peut être accompli en utilisant la recette WP-CLI sous "Autre".

L'hôte et le nom d'utilisateur seront généralement les mêmes que ceux que nous avons utilisés lors de l'étape de déploiement, et vous pouvez enchaîner autant de commandes que nécessaire.

Conclusion

Si vous êtes toujours aux prises avec des bouffonneries de codage de cow-boy et/ou des versions anxiogènes, jetez un œil à Branch et facilitez les déploiements !