Intégration continue centrée sur WordPress avec CircleCI
Écrire sur l’intégration continue ou les déploiements continus me semble un peu drôle étant donné que je l’ai déjà fait et que je sais que beaucoup de développeurs l’utilisent déjà dans leur quotidien.
Mais je sais aussi qu’il y a beaucoup d’amateurs, de débutants et de débutants qui cherchent des moyens de s’assurer qu’ils mettent en place des pratiques solides pour leur travail.
Pour ce que ça vaut, ce n’est que lorsque j’ai commencé à travailler avec quelques personnes supplémentaires que nous avons commencé à intégrer un ensemble plus large d’outils dans notre processus de déploiement.
Et c’est le but de ce post.
C’est-à-dire:
- présenter toute l’idée derrière l’intégration continue centrée sur WordPress,
- présentant CircleCI ,
- préparez-vous à en discuter davantage.
Cela dit, voici le récapitulatif de tout ce qui précède.
Intégration continue centrée sur WordPress
Tout d’abord, quelle est la grande idée derrière l’intégration continue de toute façon ? La définition générale de l’intégration continue est donc :
En génie logiciel, l’intégration continue (CI) est la pratique consistant à fusionner toutes les copies de travail des développeurs dans une ligne principale partagée plusieurs fois par jour.
Selon le système de contrôle de code source choisi, ce qui est considéré comme votre "ligne principale" variera. Si vous utilisez GitHub, ce sera probablement votre branche principale (c’est pourquoi nous devrions toujours travailler dans des branches séparées, avoir des révisions de code, et configurer des demandes d’extraction).
Ensuite, prenez tout ce qui se trouve dans master et déployez-le sur votre serveur intermédiaire ou votre serveur de production.
Et bien qu’il existe de nombreux outils pour cela, mon équipe et moi utilisons CircleCI pour quelques projets et je suis définitivement fan (en plus, ils viennent de publier la deuxième version de leur travail).
1 Qu’est-ce que CircleCI ?
CircleCI se définit simplement comme :
Créez des environnements personnalisés, appliquez des workflows pour contrôler votre pipeline de build, profitez d’une allocation flexible des ressources, et bien plus encore.
À propos de laquelle j’ai des sentiments mitigés. Je veux dire, tout est vrai et cela nous permet d’avoir une personnalisation sur un certain nombre d’aspects différents de nos déploiements, mais en termes d’être moins intimidant pour ceux qui débutent, je ne sais pas.
Quoi qu’il en soit, j’ai constaté que cela peut être aussi simple ou aussi complexe que les besoins de votre projet. Et puisqu’il s’agit plus d’en partager les raisons, je ne vais pas m’attarder sur tout ce qu’il propose.
Du moins pas dans ce post.
2 Comment l’utilisons-nous ?
En supposant que vous ayez déjà configuré un projet GitHub, il est très facile de connecter CircleCi à votre projet.
Chaque fois que vous vous inscrivez, vous pouvez vous connecter avec GitHub, Bitbucket ou Google (bien que je sois fan de commencer avec GitHub ou Bitbucket étant donné qu’ils ont les référentiels pour le code que beaucoup d’entre nous dans WordPress, au moins, utilisent le plus couramment) .
À partir de là, vous devrez configurer un webhook pour CircleCI. Cela permettra essentiellement à CircleCI de parcourir la variété d’outils que vous avez configurés et de construire votre projet. J’en parlerai plus dans un instant.
- Si la construction réussit, vous recevrez une telle notification et vous pourrez demander une révision du code ou fusionner la branche dans master.
- Si la construction échoue, elle bloquera (et devrait) bloquer la possibilité de fusionner la branche jusqu’à ce qu’il y ait une construction réussie.
Cela dit, que pourraient inclure les outils faisant partie d’un processus de construction pour un projet WordPress? Étant donné qu’une grande partie d’un projet WordPress inclut généralement PHP et JavaScript, vous pouvez en utiliser quelques-uns :
- GrumPHP
- Renifleur de code PHP
- PHPMD
- ESLint
- Et beaucoup plus.
Si vous avez correctement configuré GrumPHP, il surveillera chaque commit qui entre dans votre référentiel (même s’il s’agit d’un commit local, c’est-à-dire avant que vous ne poussiez en amont vers GitHub).
Ainsi, vous devez savoir s’il y a un problème avec votre code avant même de le pousser en amont. Une fois les vérifications locales terminées, vous êtes alors prêt à le pousser vers votre référentiel. CircleCI exécutera alors les mêmes opérations en fonction de votre configuration dans l’environnement que vous avez configuré.
Si tout se passe bien, cela passera et, comme mentionné, vous pourrez le fusionner. Sinon, vous devrez corriger les erreurs qu’il signale, réengager et pousser. Habituellement, s’il passe un commit local, il passera un push. Mais ce n’est pas toujours le cas, alors ne supposez pas autant.
Plus à venir
De toute évidence, cela ne fait qu’effleurer la surface de ce que l’intégration continue peut faire. Honnêtement, je ne sais même pas si je dirais cela – il s’agit plutôt d’introduire l’idée d’intégration continue et les avantages qu’elle procure, en particulier lorsque l’on travaille en équipe.
Bien que j’aie essayé une variété d’outils différents, je dois dire que j’ai été très satisfait de ce qu’offre CircleCI. L’une des choses les plus intéressantes est que si vous choisissez de construire sur une boîte Linux, son utilisation est gratuite. Et cela fonctionne bien pour une petite équipe qui cherche à rester maigre.
Quoi qu’il en soit, il y a plus à couvrir à ce sujet, donc je cherche à le faire dans les prochains articles.