Déploiement Git : mettre son site en ligne

L'extension Git de Plesk est ouverte sur toutes nos offres d'hébergement, comme le présente la page déploiement Git. Les étapes ci-dessous suivent la documentation de Plesk sur les dépôts distants, rédigée en anglais : les libellés français de votre panneau peuvent différer.

Relier un dépôt distant

Dans votre espace client, ouvrez votre service d'hébergement et cliquez sur « Se connecter à Plesk ».
Dans Sites Web & Domaines, ouvrez votre domaine et cliquez sur Git, puis sur Ajouter un dépôt s'il en existe déjà un.
Choisissez la source distante (« Remote git hosting »), puis collez l'adresse du dépôt dans le champ du dépôt distant.
Pour un dépôt privé, donnez l'adresse au format SSH, de la forme [email protected]:compte/projet.git. Plesk affiche alors une clé SSH publique qu'il vient de générer : ajoutez-la comme clé de déploiement dans les réglages du dépôt, sur GitHub ou GitLab, avant de valider.
Vérifiez le dossier de destination : par défaut, httpdocs, la racine du site. Cliquez sur son nom pour en choisir un autre.
Validez. Plesk clone le dépôt, qui apparaît ensuite dans la liste Git du domaine.

La clé de déploiement donne à Plesk un accès en lecture au seul dépôt où vous l'avez ajoutée, pas à votre compte GitHub ou GitLab.

Choisir le mode de déploiement

Plesk propose trois modes, d'après sa documentation sur les dépôts locaux :

Mode	Ce qui se passe
Automatique	chaque envoi sur la branche choisie est copié en ligne aussitôt
Manuel	les fichiers ne partent qu'au clic sur le bouton de déploiement
Aucun	le dépôt est seulement conservé, rien n'est copié

L'automatique est le mode par défaut. Il fait gagner du temps, mais un envoi fait par erreur part en ligne aussi vite. Le manuel ajoute un clic et une vérification. Le mode se change dans les réglages du dépôt (Repository Settings).

Déployer à chaque envoi : le webhook

En mode automatique, Plesk doit savoir qu'un envoi a eu lieu. Il génère pour cela une adresse de webhook :

Dans la liste Git du domaine, ouvrez les réglages du dépôt et copiez l'adresse du webhook.
Sur GitHub ou GitLab, ouvrez les réglages du dépôt, rubrique des webhooks, et ajoutez cette adresse, déclenchée à chaque envoi (push).
Faites un envoi d'essai sur la branche choisie, puis vérifiez dans Plesk que la date du dernier déploiement a changé.

Notre panneau Plesk, joignable à hub.hubspace.fr, porte un certificat valide : une adresse de webhook qui commence par https://hub.hubspace.fr:8443 s'utilise telle quelle, sans désactiver la vérification du certificat côté GitHub ou GitLab.

Les commandes après déploiement

Plesk peut exécuter des commandes après chaque copie, une par ligne : installer des dépendances, migrer une base, vider un cache. On les active dans les réglages du dépôt, en cochant l'option des actions de déploiement supplémentaires.

Ces commandes tournent avec les droits de votre compte d'hébergement. D'après la documentation de Plesk, sans accès SSH complet elles s'exécutent dans un environnement isolé, où les programmes du serveur, comme Composer ou npm, ne sont pas disponibles. L'accès SSH complet est compris à partir de l'offre Sérénité, à condition de l'avoir activé dans Plesk (Hébergement et DNS, Hébergement, rubrique « Accès SSH ») : tant qu'il ne l'est pas, les commandes restent dans l'environnement isolé. Sur Départ, limitez-vous au déploiement des fichiers, ou versionnez le dossier des dépendances.

Si une commande échoue, le déploiement s'arrête et le journal indique la commande fautive. Les fichiers déjà copiés restent en place : un site peut se retrouver à moitié à jour. C'est la limite d'un déploiement par copie.

Ce qui ne doit pas être dans le dépôt

Le déploiement remplace les fichiers suivis par le dépôt, et eux seuls. Gardez donc hors du dépôt, avec un fichier .gitignore :

les fichiers envoyés par les visiteurs ou les rédacteurs, comme wp-content/uploads sur WordPress ;
les fichiers de configuration qui portent des mots de passe, comme wp-config.php, un fichier .env, ou celui de la boîte qui envoie les mails du site ;
les caches et les fichiers générés.

Un mot de passe enregistré dans l'historique d'un dépôt y reste, même effacé ensuite. Changez-le s'il y est passé.

Revenir en arrière

Le déploiement Git ne fait pas de retour arrière tout seul. Pour revenir à une version précédente, remettez l'ancien code sur la branche (par exemple avec git revert) et envoyez-le : il repart en ligne comme un déploiement normal. La base de données, elle, ne suit pas le dépôt. Votre site est aussi sauvegardé chaque nuit, et chaque sauvegarde est gardée 30 jours : la restauration se fait sur demande.

Questions fréquentes

Puis-je déployer une autre branche sur un sous-domaine de test ?

Oui : ajoutez un second dépôt pointant vers le même projet, avec l'autre branche et le dossier du sous-domaine comme destination. La création du sous-domaine est expliquée dans Créer un sous-domaine.

Faut-il un accès SSH pour utiliser Git ?

Non pour relier un dépôt distant et déployer : tout se fait depuis Plesk, sur toutes nos offres. L'accès SSH, à partir de Sérénité et une fois activé dans Plesk, sert aux commandes de déploiement qui appellent Composer ou npm, et aux opérations Git en ligne de commande.

Mon webhook ne déclenche rien, que vérifier ?

Que l'adresse copiée est complète, que l'événement choisi est bien l'envoi (push) sur la bonne branche, et que le mode du dépôt est automatique. GitHub et GitLab affichent la réponse de chaque appel dans la page du webhook : un code d'erreur y donne la piste.