Déploiement continu facile avec Buddy.works

Exemple de déploiement d’un site sous WordPress avec le thème Sage

Le but de la manœuvre est d’automatiser la mise en ligne de votre site à chaque modification. Ainsi, à chaque nouveau commit, Buddy répétera les tâches (uniquement si nécessaire) et déploiera les nouveautés directement sur le serveur.

Trigger

Sans surprise, Buddy se base sur Git pour surveiller votre code. Sur ce critère, difficile de faire plus exhaustif en terme de prise en charge :

Peu importe votre infrastructure, il y a de fortes chances que Buddy la supporte.

Dans mon cas, j’ai simplement lié mon compte Github pour pouvoir sélectionner le projet en question. Il ne reste plus qu’à choisir la branche Git que l’on souhaite surveiller, et on peut commencer à configurer notre première pipeline…

Build

Buddy utilise un système de pipelines pour chaque projet. Il s’agit d’une suite d’actions à paramétrer qui réagissent à un évènement ; généralement lors d’un nouveau push , mais il est aussi possible de ne les déclencher que manuellement (ex. vider le cache) ou bien de manière récurrente (ex. faire une sauvegarde). Vous pouvez bien sûr avoir plusieurs pipelines pour le même projet, et ainsi gérer plusieurs environnements différents (ex. staging et production).

Les différents mode de déclenchement et la sélection de la branche à surveiller.

Dans notre cas nous allons gérer la mise en ligne d’un environnement de staging à chaque push. Je ne m’attarde pas sur les options avancées que vous n’aurez certainement pas à modifier.

Une fois votre pipeline créée, vous aurez plusieurs options à votre disposition :

• Executions : liste les dernières exécutions de la pipeline, avec le statut (success/fail)
• Actions : les différentes étapes de la pipeline, vous permet de choisir parmi 95 (!) types d’actions différentes
• Filesystem : l’état actuel de votre projet (Buddy conserve une version en cache), pratique pour le debug
• Variables : variables d’environnements, clés SSH, et tout ce que vous ne souhaitez pas indexer dans Git
• Analytics : graphique des dernières exécutions sur les 30 derniers jours
• Settings : paramètres de la pipeline, en gros l’écran précédent

Concentrons-nous sur la partie Actions et voyons quelles étapes nous seront nécessaires :

Chaque étape dispose de son propre environnement, et l’état du projet est conservé entre chacune. On aura donc une image Docker PHP pour la première étape Composer, puis une image Docker Node pour compiler les assets, et enfin une action préconfigurée rsync pour transférer les modifications sur le serveur. En bonus, on pourra notifier un channel Slack à la fin de l’exécution selon l’état de la pipeline.

Composer

Ajouter une nouvelle action de type PHP et la configurer de cette manière (le nom “Composer” de l’action se personnalise dans “more options”) :

Simplement modifier la commande et remplacer le nom du dossier de votre thème bien sûr (fig. 1). Pour avoir accès à Composer, il vous suffira d’ajouter cet environnement (fig. 3) :

apt-get update && apt-get install -y git zip
curl -sS https://getcomposer.org/installer | php — — install-dir=/usr/local/bin — filename=composer

Ces commandes ne seront exécutés uniquement lorsque nécessaire (la première fois par exemple, ou si vous supprimez manuellement le cache), et ne ralentirons donc pas votre pipeline. Dans un souci d’optimisation, vous pouvez aussi, dans la partie “more options”, configurer l’option “Trigger condition” de cette manière :

Webpack

Passons à la deuxième étape qui nous permettra de compiler les assets (styles, scripts, images, etc.) avec Webpack. Le principe reste le même :

Dans notre cas nous utilisons yarn donc il suffit de l’installer dans la personnalisation de l’environnement (fig. 3) au même titre que composer. À nouveau, on peut limiter cette action à l’éventualité où le dossier qui la concerne est modifié :

Deploy

Votre dépôt est à jour sur Buddy, les dépendances PHP sont à jour grâce à Composer et vos assets compilés avec Webpack. Ne reste plus qu’à envoyer tout ça sur notre serveur.

La solution la plus simple et rapide reste SFTP. Pour autoriser Buddy à se connecter en SSH à votre serveur, vous pouvez ajouter leur clé RSA public dans votre fichier .ssh/authorized_keys que vous trouverez dans l’onglet “Variables”. Si vous n’avez pas cette possibilité, vous pouvez ajouter votre propre clé privée à Buddy, toujours dans le même onglet, pour qu’il se connecte en votre nom ; cela dit, en terme de sécurité, mieux vaut privilégier la première option ;)

Dans mon cas j’utilise une simple commande rsync, et chez Buddy ils ont poussé l’efficacité jusqu’à proposer une action pré-configurée pour ce cas de figure ; on peut même choisir le chemin de source et de destination via leur interface graphique pour être sûr de ne pas se tromper :

Cette fois-ci il faudra obligatoirement choisir certains fichiers et dossiers à ignorer pour, par exemple, ne pas envoyer tout l’index Git sur votre serveur. Pour notre cas, nous avons bêtement repris le contenu de notre .gitignore , puis ajouté .git et supprimé les dossiers dist et vendor générés par nos deux actions précédentes bien sûr :

Notification

La dernière étape consiste à créer une notification envoyée dans un channel Slack de votre choix. Pratique si vous travaillez à plusieurs, seul vous pourrez privilégier un simple email par exemple. À savoir que vous pouvez choisir de notifier qu’en cas de succès ou d’échec, ou les deux (cf le premier screenshot de l’article). Voici les différents choix de notification :

Restons sur la première option. Une fois que vous avez suivi la procédure d’autorisation de Slack, vous pouvez configurer la tâche de succès de cette façon ; pour personnaliser le contenu du message, vous avez accès à ces différents paramètres en respectant la syntaxe “Velocity Template Engine” :

✅ *<${execution.html_url}|${execution.pipeline.name} (${execution.branch.name}) #${execution.id}>*
#foreach( $commit in $execution.changelog.commits)
`${commit.revision.substring(0,8)}` ${commit.message}
#end

Pour ma part j’ai supprimé le contenu “attachment” dans les options (ça me paraissait trop peu utile pour la place utilisée dans le channel). La configuration ci-dessus aura pour résultat quelque chose comme :

Pour l’instant, le nom de l’auteur du commit n’est pas disponible dans le changelog mais l’équipe de Buddy l’a ajouté à sa wishlist. Enfin, vous pouvez aussi ajouter une notification différente en cas d’échec, dans notre cas le changelog est remplacé par les logs d’erreur, et l’emoji modifié :

⚠️ *<${execution.html_url}|${execution.pipeline.name} (${execution.branch.name}) #${execution.id}>*
#foreach( $action in $execution.action_executions)
 #if( $action.status == “FAILED” )
 #foreach( $line in $action.log)
 ${line}
 #end
 #end
#end

Fichiers d’import

Si vous souhaitez rapidement récupérer la configuration décrite ici, vous pouvez simplement importer ce fichier de configuration dans Buddy. D’ailleurs, si vous êtes allergiques aux interfaces graphiques, vous pouvez, comme avec la plupart des outils de déploiement continu, enregistrer ce fichier à la racine de votre projet en tant que buddy.yml, et Buddy l’utilisera automatiquement.

Conclusion

Performant, complet et extrêmement simple d’utilisation, Buddy m’a réconcilié avec les outils d’automatisation ; après avoir testé Bitbucket Pipelines et Travis, l’espoir renait :) Et pourtant je n’ai fait qu’effleurer l’étendue des possibilités offertes par cet outil, sans mentionner sa gratuité !

Je ne saurais que vous conseiller de l’essayer puis de partager les différents cas d’usages pour lesquels vous l’utilisez (ou comptez l’utiliser) !