Déploiement Git : déployez automatiquement votre site web grâce à la gestion de versions
Envoyer des fichiers à la main par FTP est une méthode d'un autre temps. C'est lent, source d'erreurs, et cela n'offre aucune gestion de versions. Le déploiement Git modernise ce processus : vous poussez votre code et les modifications passent automatiquement en ligne. Dans ce guide complet, j'explique comment mettre en place le déploiement Git et en tirer le meilleur parti.
Pourquoi passer du FTP au déploiement Git ?
Le workflow traditionnel de nombreux développeurs et propriétaires de sites web est simple, mais problématique. Vous modifiez des fichiers en local, vous ouvrez un client FTP, vous naviguez jusqu'au bon dossier sur le serveur, vous envoyez les fichiers modifiés et vous espérez que tout fonctionne. Ce workflow présente des problèmes fondamentaux.
Il est facile d'oublier des fichiers. Vous modifiez cinq fichiers, vous en envoyez quatre et vous vous demandez pourquoi le site ne fonctionne pas. Il est tout aussi facile d'envoyer la mauvaise version. Vous testez en local, vous oubliez d'enregistrer, vous envoyez une ancienne version et vous ne voyez pas les modifications. Il n'existe aucun historique de ce que vous avez modifié et quand. Si quelque chose casse, vous ne pouvez pas facilement revenir à une version qui fonctionne.
Le déploiement Git résout tous ces problèmes. Git garde la trace des fichiers modifiés, donc vous n'oubliez rien. Chaque modification est un commit accompagné d'une description, ce qui vous permet de savoir précisément ce que vous avez fait et quand. L'historique complet reste disponible pour y revenir si nécessaire. Et le processus de déploiement est cohérent et reproductible.
Quelles sont les différentes approches du déploiement Git ?
Git push vers un remote sur le serveur
La méthode la plus directe consiste à configurer un remote Git sur votre serveur de production. Vous poussez vers ce remote et un hook se charge d'appliquer les modifications au répertoire de votre site web. Cela nécessite un accès SSH à votre serveur et un peu de configuration, mais c'est ensuite simple à utiliser.
Pipelines CI/CD
Les pipelines d'intégration continue et de déploiement continu offrent plus de contrôle et de flexibilité. Des plateformes comme GitHub Actions, GitLab CI ou Bitbucket Pipelines détectent quand vous poussez du code vers votre dépôt. Elles exécutent alors une série d'étapes définie : lancer les tests, compiler les assets et, enfin, déployer sur votre serveur.
Cette approche est plus puissante qu'un simple git push. Vous pouvez lancer automatiquement des tests avant que le code ne passe en ligne. Vous pouvez ajouter des étapes de build pour les assets frontend. Vous pouvez déployer vers plusieurs environnements. Mais cela demande plus de mise en place et de connaissance des concepts CI/CD.
Hébergement avec intégration Git native
Certains hébergeurs intègrent le déploiement Git directement dans leur plateforme. Vous connectez votre dépôt GitHub ou GitLab et chaque push vers une branche donnée déclenche automatiquement le déploiement. Cloudways, Kinsta, Vercel et Netlify en sont des exemples. C'est l'option la plus simple si votre hébergement la prend en charge.
Outils de déploiement
Des outils comme Deployer pour PHP, Capistrano pour Ruby ou Envoy pour Laravel offrent des fonctions de déploiement avancées. Vous définissez les tâches de déploiement dans des fichiers de configuration et l'outil les exécute. C'est précieux pour les déploiements complexes en plusieurs étapes, mais excessif pour les sites simples.
Mettre en place le déploiement Git sur un VPS pas à pas
Étape un : installer Git sur le serveur
Connectez-vous à votre serveur en SSH. Installez Git s'il n'est pas déjà présent. Sur Ubuntu ou Debian, utilisez apt update suivi de apt install git. Sur CentOS ou RHEL, utilisez yum install git. Vérifiez l'installation avec git version.
Étape deux : créer un dépôt bare
Créez un répertoire pour votre dépôt Git, par exemple /var/repo/mysite.git. Allez dans ce répertoire et initialisez un dépôt bare avec git init bare. Un dépôt bare ne contient que les données Git, sans répertoire de travail ni fichiers. Il sert uniquement à recevoir des pushes.
Étape trois : configurer le hook post-receive
Toute la magie se trouve dans le hook post-receive. Il s'agit d'un script que Git exécute après avoir reçu un push. Créez le fichier hooks/post-receive dans votre dépôt bare. Ce script doit extraire le code vers le répertoire de votre site web.
Un script de base définit des variables pour le répertoire cible et l'emplacement du dépôt. Il lit les références reçues et vérifie qu'il s'agit de la bonne branche. Si c'est le cas, il extrait le code vers le répertoire cible. Rendez le script exécutable avec chmod plus x.
Étape quatre : ajouter le remote à votre dépôt local
Dans votre projet local, ajoutez un nouveau remote qui pointe vers votre serveur. Utilisez git remote add production avec l'adresse SSH de votre dépôt. Vous pouvez donner au remote le nom de votre choix ; production indique bien où le code est envoyé.
Étape cinq : déployer
Vous pouvez maintenant déployer avec une simple commande : git push production main. Git pousse vos commits vers le serveur, le hook post-receive s'exécute et votre code apparaît dans le répertoire du site web. Chaque push suivant fonctionne de la même manière.
Automatiser le déploiement avec GitHub Actions
GitHub Actions offre un moyen puissant d'automatiser le déploiement. Vous créez un fichier de workflow dans votre dépôt, sous .github/workflows. Ce fichier YAML définit quand le workflow s'exécute et quelles étapes sont réalisées.
Un workflow de déploiement de base se déclenche lors des pushes vers la branche main. Le job s'exécute sur un runner Ubuntu, extrait le code et se connecte en SSH à votre serveur pour exécuter un git pull. Vous configurez les identifiants SSH comme secrets dans les paramètres de votre dépôt GitHub afin qu'ils soient en sécurité.
L'avantage de GitHub Actions par rapport à un git push direct est que vous pouvez ajouter des étapes supplémentaires. Lancez d'abord les tests pour vous assurer que le code fonctionne. Compilez les assets frontend avec npm ou webpack. Envoyez une notification à Slack lorsque le déploiement réussit ou échoue. Les possibilités sont vastes.
Bonnes pratiques pour un déploiement Git sûr et fiable
Gardez les identifiants hors de votre dépôt
C'est crucial et non négociable. Les mots de passe, les clés d'API, les identifiants de base de données et les autres secrets n'ont pas leur place dans votre dépôt Git. Même si votre dépôt est privé, c'est un risque. Utilisez des variables d'environnement configurées sur le serveur, ou un gestionnaire de secrets. Ajoutez les fichiers sensibles à votre .gitignore.
Testez avant de déployer
Avec le CI/CD, vous pouvez lancer automatiquement des tests avant que le code ne passe en ligne. Si les tests échouent, le déploiement n'a pas lieu. Cela permet d'attraper les bugs avant qu'ils n'atteignent la production. Même sans tests automatisés, il est judicieux de tester en local avant de pousser.
Utilisez un environnement de préproduction
Ne déployez pas directement en production. Ayez un environnement de préproduction qui ressemble autant que possible à la production. Déployez d'abord là-bas, testez manuellement ou automatiquement, puis seulement ensuite déployez en production. Cela ajoute une couche de sécurité.
Envisager les déploiements atomiques
Les configurations de déploiement avancées déploient dans un nouveau répertoire, puis basculent un lien symbolique vers la nouvelle version. Si quelque chose se passe mal, vous pouvez revenir immédiatement à la version précédente en remettant le lien symbolique. L'ancienne version reste intacte. Des outils comme Deployer prennent en charge ce modèle.
Prévoir une stratégie de rollback
Sachez comment revenir à une version précédente si quelque chose se passe mal. Avec Git, c'est techniquement simple : vous pouvez annuler un commit (revert) ou réinitialiser (reset) vers un état antérieur. Mais entraînez-vous avant d'en avoir besoin en pleine crise. Connaissez les commandes et sachez comment elles fonctionnent.
Points d'attention spécifiques pour WordPress et Git
WordPress demande une attention particulière lors d'un déploiement Git. Le fichier wp-config.php contient les identifiants de la base de données et n'a pas sa place dans votre dépôt. Ajoutez-le à .gitignore et gérez-le séparément sur le serveur. Le répertoire uploads contient des médias téléversés par les utilisateurs et n'a pas non plus sa place dans Git. Utilisez .gitignore et gérez les médias séparément ou via un CDN (réseau de diffusion de contenu).
La base de données elle-même contient du contenu et des paramètres qui ne passent pas par Git. Les migrations de base de données sont plus complexes qu'un déploiement de fichiers. Envisagez un outil comme WP Migrate ou un workflow avec des exports de base de données.
Bedrock est une stack WordPress moderne qui fonctionne mieux avec Git. Elle structure WordPress comme une dépendance et sépare la configuration du code. Si vous voulez travailler sérieusement avec WordPress et Git, Bedrock mérite d'être étudié.
Erreurs courantes et comment les éviter
Une erreur courante consiste à déployer sans tester. Ça marche en local, donc ça marchera sûrement en production, non ? Non. Les différences d'environnement, les dépendances manquantes et les écarts de configuration peuvent causer des problèmes. Testez toujours.
Committer des identifiants est une autre erreur aux conséquences sérieuses. Même si vous les supprimez ensuite, ils restent dans l'historique Git. Utilisez git-secrets ou des outils similaires pour éviter de committer des secrets par inadvertance.
Ne pas surveiller après le déploiement est également risqué. Vous déployez et vous supposez que tout fonctionne. Vérifiez pourtant réellement que le site tourne et que les fonctions critiques marchent. Automatisez cela dans la mesure du possible.
Le déploiement Git transforme la façon dont vous gérez vos sites web. La configuration initiale prend du temps, mais les avantages en vitesse, en fiabilité et en traçabilité en valent largement la peine. Commencez simplement avec une configuration git push de base et passez au CI/CD à mesure que vos besoins évoluent.
Checklist du déploiement Git et bonnes pratiques
Un déploiement Git réussi demande une approche structurée. Utilisez la checklist ci-dessous pour que chaque déploiement Git se déroule sans accroc.
- Vérifiez que toutes les modifications sont commitées avant le déploiement Git
- Lancez les tests en local avant de démarrer un déploiement Git
- Utilisez des feature branches et ne mergez vers main qu'après une revue
- Configurez un déploiement Git automatique via des pipelines CI/CD
- Gardez une stratégie de rollback prête pour chaque déploiement Git
- Documentez chaque déploiement Git dans un changelog
| Méthode de déploiement Git | Complexité | Adapté à |
|---|---|---|
| Git pull manuel | Faible | Petits projets |
| Hooks Git (post-receive) | Moyenne | Serveur unique |
| CI/CD (GitHub Actions) | Moyenne à élevée | Équipes et projets professionnels |
| Kubernetes + GitOps | Élevée | Entreprises et microservices |
Que vous hébergiez un site web simple sur un VPS ou que vous gériez une application complexe, le déploiement Git rend la gestion de votre code claire et fiable. Associez le déploiement Git à un bon environnement d'hébergement pour obtenir les meilleurs résultats.
Comment mettre en place votre déploiement Git : pipelines CI/CD ?
L'étape suivante après le déploiement Git manuel est la mise en place d'un pipeline CI/CD (intégration continue/déploiement continu) automatisé. Votre code est alors testé et déployé automatiquement dès que vous poussez vos modifications vers votre dépôt.
GitHub Actions pour le déploiement
GitHub Actions est un choix populaire pour le déploiement automatisé. Vous définissez des workflows dans des fichiers YAML qui sont exécutés à chaque push. Un workflow de déploiement typique comprend les étapes suivantes :
- Récupérer le code depuis le dépôt
- Installer les dépendances (npm install, composer install)
- Exécuter les tests (tests unitaires, tests d'intégration)
- Compiler les assets (CSS, JavaScript)
- Déployer sur le serveur de production via SSH ou rsync
GitLab CI/CD comme alternative
GitLab propose une solution CI/CD intégrée particulièrement puissante. Le pipeline est défini dans un fichier .gitlab-ci.yml à la racine de votre dépôt. GitLab prend également en charge les environnements, les review apps et le déploiement automatique vers des clusters Kubernetes.
Comment comparer les stratégies de déploiement Git ?
Il existe plusieurs stratégies de déploiement Git, chacune avec ses avantages et ses inconvénients.
| Stratégie | Indisponibilité | Complexité | Rollback | Adapté à |
|---|---|---|---|---|
| Déploiement direct | Courte | Faible | Git revert | Petits projets |
| Déploiement blue-green | Aucune | Moyenne | Instantané (bascule) | Environnements de production |
| Déploiement rolling | Aucune | Élevée | Progressif | Plusieurs serveurs |
| Déploiement canary | Aucune | Élevée | Rapide | Grandes applications |
Le déploiement blue-green expliqué
Avec le déploiement blue-green, vous exploitez deux environnements de production identiques : « blue » (version actuelle) et « green » (nouvelle version). Vous déployez le nouveau code dans l'environnement green, vous le testez à fond, puis vous basculez le trafic de blue vers green. En cas de problème, vous rebasculez immédiatement.
Bonnes pratiques pour le déploiement Git
Pour que votre processus de déploiement Git reste fiable et sûr, suivez ces bonnes pratiques :
- Utilisez des feature branches : développez les nouvelles fonctionnalités sur des branches distinctes et ne mergez vers main que lorsque tout est testé
- Automatisez les tests : ne laissez jamais déployer du code qui n'a pas passé tous les tests
- Configuration hors du dépôt : stockez les mots de passe, les clés d'API et les autres données sensibles dans des variables d'environnement, pas dans votre code
- Exécutez les migrations de base de données séparément : lancez les migrations avant de déployer le nouveau code pour éviter les problèmes de compatibilité
- Monitoring après le déploiement : mettez en place un monitoring de disponibilité pour détecter les problèmes juste après le déploiement
- Documentez votre processus de déploiement : assurez-vous que chaque membre de l'équipe peut l'exécuter, pas seulement le développeur principal
Avec un processus de déploiement Git bien en place, vous économisez des heures de travail manuel par semaine et vous réduisez le risque d'erreurs lors de la mise en ligne de modifications sur votre site web.
Déploiement Git : éviter les erreurs courantes
Lors de la mise en place d'un déploiement Git, les mêmes erreurs reviennent régulièrement et causent des problèmes lors de la mise en ligne des modifications. Connaissez ces pièges et évitez-les.
L'erreur la plus fréquente est de committer des informations sensibles dans le dépôt. Les mots de passe, les clés d'API et les données de base de données n'ont pas leur place dans votre codebase. Utilisez un fichier .gitignore pour exclure les fichiers de configuration et conservez les données sensibles dans des variables d'environnement. Si vous avez commité des secrets par erreur, il ne suffit pas de les supprimer dans un nouveau commit : ils restent dans l'historique Git. Utilisez des outils comme git-filter-repo pour réécrire l'historique.
Une autre erreur fréquente est de déployer directement en production sans utiliser d'environnement de préproduction. Testez toujours vos modifications d'abord sur un environnement identique à la production. Cela évite que des bugs, des conflits ou des problèmes de configuration ne soient découverts qu'une fois sur le serveur de production. Automatisez ce processus en configurant votre pipeline CI/CD de façon à déployer d'abord les modifications en préproduction.
N'oubliez pas non plus de rendre vos scripts de déploiement idempotents. Cela signifie que le script produit le même résultat, quel que soit le nombre de fois où vous l'exécutez. Si un déploiement échoue en cours de route et que vous le relancez, cela ne doit causer aucun problème. Utilisez des vérifications conditionnelles et des transactions dans vos scripts de migration pour le garantir. Avec de bonnes pratiques de migration et des tests automatisés, vous construisez un système de déploiement robuste qui donne confiance à votre équipe à chaque release.
Déploiement Git : se lancer avec votre premier pipeline
Si vous n'avez pas encore d'expérience du déploiement Git automatisé, commencez par une configuration simple que vous pourrez étoffer progressivement. La façon la plus simple de démarrer est un hook post-receive sur votre serveur de production. C'est un script qui s'exécute automatiquement lorsque vous poussez du code vers le serveur. Le script récupère le dernier code et redémarre le serveur web si nécessaire.
Une étape de plus consiste à mettre en place un workflow GitHub Actions. Créez un fichier dans votre dépôt au chemin .github/workflows/deploy.yml. Définissez-y les étapes à exécuter à chaque push vers la branche main : récupérer le code, lancer les tests et déployer via SSH. GitHub propose de nombreuses minutes gratuites pour les dépôts publics et privés, ce qui vous permet de démarrer sans frais supplémentaires. Commencez simplement et ajoutez progressivement des étapes à mesure que votre confiance grandit. Un pipeline CI/CD n'est jamais terminé : il évolue avec votre projet et devient de plus en plus fiable à mesure que vous ajoutez des tests et des contrôles au processus.
Déploiement Git : conclusion et prochaines étapes
Avec un système de déploiement Git bien conçu, vous faites passer votre workflow de développement à un niveau professionnel. Les avantages sont indéniables : chaque modification est traçable, le retour en arrière est simple et la collaboration entre plusieurs développeurs se déroule sans conflit. Commencez simplement avec un workflow de base qui déploie automatiquement sur votre serveur de production à chaque push vers main. Ajoutez progressivement d'autres étapes : tests automatisés, linting, analyses de sécurité et notifications. Documentez votre processus de déploiement pour que chaque membre de l'équipe puisse l'exécuter et le comprendre. Investissez dans un environnement de préproduction pour tester les modifications avant leur mise en ligne. Avec ces briques, vous créez un processus de déploiement fiable et reproductible, qui vous donne confiance à chaque release et réduit au minimum le risque d'erreur humaine.
Bonnes pratiques de déploiement Git pour les équipes
Lorsque vous travaillez en équipe avec le déploiement Git, d'autres bonnes pratiques permettent de fluidifier le processus. Utilisez des règles de protection de branche (branch protection rules) pour empêcher quiconque de pousser directement vers main sans revue de code. Imposez des revues de pull request afin qu'au moins un membre de l'équipe approuve chaque modification avant qu'elle ne soit mergée. Utilisez des messages de commit conventionnels, au format fixe, pour que l'historique reste lisible et que des changelogs puissent être générés automatiquement. Mettez en place des rollbacks automatiques qui restaurent la version précédente si un déploiement échoue ou si le monitoring détecte que la nouvelle version provoque des erreurs. Gardez vos branches courtes : les feature branches qui existent depuis plus d'une semaine deviennent difficiles à merger et provoquent des conflits. Avec ces pratiques, vous construisez un pipeline de déploiement robuste qui a la confiance de toute l'équipe.
