Déploiement automatique avec Git Push : expérience cloud sur votre propre serveur

« git push origin main » et quelques secondes plus tard, votre site est en ligne, l’expérience que les plateformes cloud modernes ont rendue standard. Cette commodité est désormais devenue notre attente. Cependant, mettre en place la même expérience sur notre propre serveur est souvent plus compliqué qu’on ne le pense : secrets de webhook, build runners, gestion des artefacts, swap atomique…

Dans cet article, nous expliquerons ce qui se cache derrière le mécanisme de déploiement automatique avec git push et comment vous pouvez configurer ce système sur votre propre VPS.

Comment fonctionne « git push = deploy » ?

Il y a trois composants de base :

1. 01
   webhook

   Le référentiel Git envoie HTTP POST à ​​chaque push. Il contient des informations sur quelle branche, qui s'engage et par qui.
2. 02
   Récepteur

   Le point de terminaison sur votre serveur qui écoute le webhook. Il vérifie la signature HMAC-SHA256 de la demande entrante et vérifie qu'il s'agit d'un push légitime.
3. 03
   pipeline

   Une fois la signature vérifiée, il extrait le code, le construit, remplace le service existant par un nouvel artefact (échange atomique), effectue un contrôle de santé et notifie le résultat.

Il n’est pas techniquement difficile de coder chacun de ces 3 composants à la main, mais cela prend beaucoup de temps pour les rendre de qualité production : rollback, protection contre les déploiements simultanés, build cache, streaming de journaux, gestion des secrets…

Configuration du Webhook, manuel

Un exemple de récepteur de webhook (Node.js + Express) :

P0

Et P0 :

P1

Solution de niveau production : déploiement de git push avec VDS Panel

VDS Panel offre une intégration de webhook intégrée. L’installation est un travail d’une minute :

1. 01
   Liez votre compte GitHub

   La liste des référentiels est extraite avec GitHub OAuth dans les paramètres du panneau.
2. 02
   Créer le projet

   Sélectionnez Référentiel. Le panneau installe automatiquement le webhook, vous n'avez pas besoin de créer de secret dans les paramètres de GitHub.
3. 03
   Commencez à pousser

   À chaque poussée git suivante, le panneau capture le webhook, vérifie la signature et démarre le pipeline.

Dès que vous définissez P0, le panneau :

1. Cloner superficiellement le code (rapide)
2. Détection du framework (package.json/pom.xml/go.mod/Dockerfile)
3. Vérification du cache de dépendance (ignorer si le cache npm/maven/go est le même)
4. Build (parallèle : image + migration DB + contrôle SSL)
5. Échange atomique vers la production d’artefacts (l’ancienne version est conservée pendant 5 minutes, la restauration est rapide)
6. Bilan de santé (sonde de préparation pendant 30 secondes)
7. Succès → rechargement de nginx. Échec → restauration automatique.

Les flux de processus sont en direct dans l’interface du panneau : journal de construction, résultats des tests, état du déploiement, le tout en temps réel.

Scénarios avancés

Déploiement basé sur une branche

Le panel peut déployer la production pour la branche P0 et la préparation pour P1. Chaque branche obtient des sous-domaines distincts : P2 et P3. DNS + SSL est automatiquement établi.

Approbation manuelle (porte d’approbation)

Vous pouvez activer le mode « approbation manuelle » pour les environnements de production critiques en matière de sécurité. Lorsque la poussée arrive, le panneau construit mais met le déploiement en attente ; Il n’est pas mis en ligne sans l’approbation d’un utilisateur.

###Restaurer

Cliquez sur “Revenir à la version précédente” sur l’écran de déploiement. Le panneau stocke l’artefact des 10 derniers déploiements réussis ; Il effectue des échanges instantanés vers ce que vous voulez. Il s’intègre également à des outils tels que Flyway/Liquibase pour inverser les migrations de bases de données.

Secret multi-environnement

Variables d’environnement séparées pour les tests, la préparation et la production. Les secrets spécifiques à chaque environnement sont stockés dans le coffre-fort secret et injectés au moment de l’exécution.

Construire des arguments

La transmission de build arg à Dockerfile, l’appel d’une tâche personnalisée à Gradle et l’exécution d’un script de pré-déploiement sont tous gérés à partir de l’interface du panneau.

Conclusion

L’expérience « git push = deploy » est indispensable pour un développeur moderne. Il est possible de mettre en place la même expérience sur votre propre serveur sans payer de frais cloud pour les services de déploiement cloud modernes, il s’agit simplement de savoir combien de temps vous pouvez consacrer.

L’installer vous-même est un travail de 2 à 3 semaines ; Avec VDS Panel, l’intégration du webhook s’effectue automatiquement lors de la création du premier projet. Pour plus de détails, vous pouvez consulter notre page de fonctionnalités ou demander une démo.