Déploiement en direct et mise en scène avec Deploybot

Si vous êtes dans le développement Web depuis un certain temps, vous avez probablement foiré un transfert de fichiers alors que vous essayez de mettre à jour un site. Dans le meilleur des cas, vous ajoutez un tas de fichiers facilement identifiables à un répertoire et vous les supprimez pour corriger l'erreur. Oui, cela vous coûte du temps et c'est ennuyeux, mais pas de mal.

Dans le pire des cas, vous transférez un tas de fichiers de thème de manière incorrecte. Ensuite, vous devez déterminer lesquels ont été écrasés, lesquels n'appartiennent pas du tout, et comment diable allez-vous récupérer le bon état de fonctionnement de votre thème.

Aujourd'hui, nous allons nous attaquer à la résolution de ce problème en utilisant Git et Deploybot pour automatiser votre processus de déploiement.

Qu'est-ce que le déploiement automatisé ?

Un déploiement automatisé de base comporte quatre éléments, comme illustré dans ce diagramme.

La plupart des développeurs commencent uniquement avec leur code et le serveur. Ils apportent des modifications à leur copie de travail du site, puis transmettent ces modifications directement au serveur via FTP. Des outils comme Coda ou Dreamweaver ont une intégration FTP directe afin que vous puissiez le faire depuis votre environnement de codage.

La prochaine étape que de nombreux développeurs franchissent consiste à ajouter un site intermédiaire afin qu'ils ne modifient pas directement le serveur en direct. Vous pouvez le faire avec quelque chose comme VVV ou MAMP. Souvent, cela signifie également que vous utilisez un système de contrôle de version comme Git pour gérer les modifications que vous apportez à votre site de travail local.

Lorsque vous ajoutez un site intermédiaire, vous ajoutez également de la complexité. Comment obtenez-vous vos modifications de code de votre site de travail local vers un site intermédiaire où votre client peut voir les modifications ? Oui, comme je l'ai déjà dit, vous pouvez utiliser un client FTP de base comme FileZilla, Transmit ou Forklift pour déplacer les fichiers au fur et à mesure que vous apportez des modifications, mais cela est sujet aux erreurs et c'est là que l'automatisation de votre processus de déploiement vous fera gagner beaucoup de temps.

Au lieu de prendre les fichiers que vous modifiez et de les transférer sur votre serveur de transfert, vous utilisez un autre système pour détecter automatiquement les modifications dans votre référentiel Git et ne transférer que ces modifications sur le site de transfert que votre client peut utiliser pour vérifier le travail.

Cela laisse toujours votre site en direct comme un déploiement manuel, ce qui est beaucoup plus effrayant car cela peut signifier la perte d'argent réel si vous supprimez un site de travail en direct. Au lieu de cela, supposons que vous allez configurer votre système de déploiement pour un déploiement automatique vers la mise en scène, puis votre système se déploiera en un seul clic vers l'environnement en direct lorsque vous serez prêt à partir.

Alors maintenant, vous avez un système qui ressemble à ceci.

Plongeons-nous pour que je puisse vous montrer comment j'ai configuré ce processus de déploiement pour chaque client avec lequel je travaille. Ce sont les étapes que je franchis dès que je démarre un nouveau projet. Je m'assure toujours que mon processus de déploiement est configuré et fonctionne avant de commencer tout autre travail sur un projet client.

Comment structurer votre référentiel Git

Votre premier choix à faire est de savoir dans quel répertoire allez-vous configurer votre déploiement automatisé ? À moins que mon client ne demande spécifiquement ce contrôle total de la source pour son installation WordPress, j'utilise le répertoire wp-content pour configurer mon système de déploiement automatisé. Cela commence dans le terminal en émettant cette commande qui initialise un référentiel git.

git init

Il est maintenant temps d'ignorer les fichiers que vous ne voudrez pas déployer tout le temps. Il s'agit de fichiers tels que des fichiers de sauvegarde, des images et tous les fichiers de projet personnalisés que de nombreux éditeurs de code ajoutent à un répertoire. Vous pouvez voir mon fichier .gitignore habituel ci-dessous.

config/app_config.yml

config/database.yml

config/*.sphinx.conf

config/s3_credentials.yml

*~

*.cache

*.Journal

*.pid

tmp/**/*

.DS_Store

db/cstore/**

db/sphinx/**

doc/api

doc/application

doc/plugins

doc/*.dot

couverture/*

db/*.sqlite3

*.tmproj

*.sw?

*.esproj

_Remarques*

dwsync.xml

podcast.xml

*.kpf

*téléchargements/*

*.swp

*.idée

*.sublime-projet

*.sublime-workspace

*/node_modules/*

Mots clés

*.bak

cache/*

managewp/*

mu-plugins/*

dp.php

courant ascendant/*

langues/*

db.php

plugins/wp-rocket/cache.json

N'hésitez pas à en ajouter ou à en retirer au besoin. Presque tous les projets sur lesquels je travaille ont besoin d'une sorte d'entrée personnalisée pour ignorer un fichier spécifique à mon site de travail local pour lequel les sites de mise en scène et en direct auront leur propre fichier personnalisé que je ne veux pas écraser.

À partir de là, il est temps de configurer les branches dont vous aurez besoin pour lancer votre système de déploiement. J'utilise deux branches principales. La première est la branche master qui correspond à mon site de production live. Deuxièmement, il s'agit d'une branche que j'appelle staging et qui correspond au site de staging que je souhaite que mon client utilise pour vérifier les modifications que nous apportons.

Lorsque vous avez initialisé votre référentiel Git, vous avez déjà votre branche principale, utilisez donc cette commande pour ajouter une branche intermédiaire et la vérifier.

git checkout -b mise en scène

Cette commande crée et extrait une nouvelle branche. Si vous débutez avec git, vous pouvez trouver plus d'informations sur les commandes disponibles dans la documentation de Git.

Vous devez maintenant pousser votre projet dans votre système de contrôle de code source. Github et Bitbucket sont deux choix populaires qui fonctionnent tous les deux avec le système de déploiement automatisé que nous allons utiliser appelé Deploybot. Lorsque vous créez un nouveau référentiel avec l'un ou l'autre des sites, ils vous donneront des instructions supplémentaires pour ajouter votre référentiel local à votre version en ligne dans Github ou Bitbucket.

• Documentation de configuration du référentiel Bitbucket
• Documentation de configuration du référentiel Github

Configuration de Deploybot

Lorsque je me lançais pour la première fois dans un travail plus complexe en tant que développeur, mon ami Duane n'arrêtait pas de me recommander Deploybot lorsque je me plaignais en ligne d'avoir gâché le déploiement manuel du FTP. Il a fallu un certain nombre de recommandations avant que je fasse enfin ce qu'on m'a dit, mais je suis maintenant un client satisfait de Deploybot depuis des années.

Bien qu'il existe d'autres moyens de déployer vos sites, beaucoup d'entre eux impliquent une interface avec Git Webhooks ou certains fichiers de configuration de déploiement automatisé via votre éditeur de code. Il y a beaucoup de puissance dans ces autres outils, mais si vous débutez avec le déploiement automatisé, alors allez avec quelque chose de simple comme Deploybot est le point de départ.

Pour commencer, créez un compte Deploybot et connectez Github ou Bitbucket à votre compte. J'utiliserai mon compte Bitbucket existant aujourd'hui. Commencez par ajouter un nouveau référentiel à votre compte Deploybot.

Une fois que vous avez trouvé le référentiel que vous souhaitez configurer pour le déploiement automatisé, cliquez sur le bouton intitulé se connecter en bas de la page. Cela vous renverra à la page de votre référentiel pendant que Deploybot termine l'initialisation de votre référentiel. Généralement, cela se fait en une minute ou deux, alors remplissez votre café et revenez pour terminer la configuration de votre processus de déploiement.

Une fois votre référentiel configuré, cliquez dessus pour accéder à sa page principale. Étant donné que nous n'avons pas encore configuré d'informations sFTP, une grande boîte vous indiquera de configurer un serveur. Cliquez sur le bouton pour créer un environnement et un serveur.

Commençons par le déploiement dans notre environnement intermédiaire. Alors étiquetez votre serveur comme intermédiaire. Choisissez le déploiement automatique et assurez-vous de définir la branche sur staging.

Lorsque vous avez terminé, cliquez sur le bouton Enregistrer en bas de la page pour passer à la configuration de votre serveur.

Sur la page suivante, étiquetez-le à nouveau en tant que serveur intermédiaire et insérez vos informations sFTP à partir de votre site. Si vous ne savez pas où les trouver, lisez ce guide utile.

Une fois vos informations sFTP saisies, vous pouvez faire défiler vers le bas et les enregistrer. Deploybot testera ensuite votre connexion pour s'assurer que les informations que vous avez fournies fonctionnent. Il est maintenant temps de faire notre déploiement initial pour le site afin de s'assurer que tout fonctionne. J'ajoute souvent un fichier test.txt au déploiement comme moyen simple de vérifier que le déploiement a fonctionné correctement.

Pour démarrer votre déploiement dans l'historique de votre environnement et cliquez sur déployer.

Vous verrez maintenant une page avec votre dernier message de validation git comme la note que vous verrez dans Deploybot à côté de ce déploiement. Pour les gros changements, je changerai cela, mais si je ne fais que changer le CSS ou quelque chose de mineur, le message de validation peut rester. Puisqu'il s'agit d'une mise en scène, chaque validation de notre branche de mise en scène sera déployée automatiquement, ce qui signifie que vos messages de validation seront affichés. C'est seulement le commit initial que nous devons faire manuellement sur notre site de staging.

Vérifiez maintenant que vos fichiers ont été publiés sur le site intermédiaire et nous pouvons configurer le déploiement en direct.

Pour votre déploiement en direct, assurez-vous de ne pas choisir le déploiement automatique et assurez-vous de choisir la branche principale comme source de votre déploiement. Nous voulons qu'il s'agisse d'un déploiement manuel lorsque nous sommes prêts à apporter des modifications à notre site en ligne.

Pour ce faire, vous devrez vérifier votre branche master, puis fusionner vos modifications de votre branche intermédiaire dans master.

Vous pouvez le faire avec ces commandes.

maître de caisse git

mise en scène de fusion git

maître d'origine git push

Désormais, lorsque vous accéderez à votre compte Deploybot, vous pourrez déployer manuellement vos modifications, comme nous l'avons fait lors de notre déploiement initial dans notre environnement intermédiaire. Pour votre environnement en direct, assurez-vous de modifier le message de déploiement en fonction des modifications qui sont transmises à votre site en direct. Vous devez également créer une sauvegarde de votre site. Vous pouvez le faire en accédant à la navigation des sauvegardes sur votre site, puis en créant une sauvegarde manuelle.

Voilà, vous avez la configuration de votre système de déploiement automatisé pour les environnements de mise en scène et en direct.

Autres considérations de déploiement

Bien que ce système soit un grand pas en avant pour la plupart des développeurs, il n'est pas sans poser de problèmes. Le plus important étant que si vous avez un tas de modifications, vous attendez toujours que FTP ait fini de transférer les fichiers qui ont été modifiés. Cela peut signifier que quelqu'un visite votre site et que tous les fichiers dont votre site a besoin pour fonctionner ne sont pas présents.

Pour de nombreux clients, cela ne posera pas de problème, mais si c'est pour votre site, vous devrez envisager de configurer un système de déploiement Atomic. Ce type de système de déploiement déplace tous les fichiers, vérifie qu'ils fonctionnent correctement, puis modifie les paramètres des fichiers sur votre serveur afin que le nouveau répertoire soit désormais celui qui exécute votre site.

Le processus de création d'un lien vers un nouveau dossier prend si peu de temps que seul un ordinateur le remarquerait. Cela signifie également que si vous trouvez un problème plus tard, vous pouvez modifier votre lien système vers l'ancienne version du site pour revenir à la version qui fonctionnait. Encore une fois, cela ne prend que très peu de temps et réduit les temps d'arrêt.

Peu importe ce que vous choisissez de faire, arrêtez d'utiliser un client FTP pour déployer vos fichiers clients dès aujourd'hui. Le petit coût mensuel de Deploybot est récupéré chaque fois que vous ne faites pas d'erreur en déployant vos fichiers.