Déployer sur l'environnement de développement

La fonction de déploiement vous offre la possibilité de déployer une branche de votre repository GitLab dans votre environnement de développement.

Contexte du déploiement

Lorsque vous déployez sur un environnement hyperlane, tout ce qui n'est pas présent :

- dans les répertoires montés : img, override, upload, modules, mails, themes, translations, config, download
- Ou versionné par le .gitignore

SERA SUPPRIMÉ

Si vous avez besoin de garder des dossiers lourds sans les versionner, vous pouvez créer des liens symboliques en suivant la documentation suivante: Créer des liens symboliques (symlink)

 

Les commits automatiques

L'environnement de développeur possède une fonction permettant de toujours committer automatiquement les derniers changements.
Cela permet de toujours avoir une trace sur git des changements en local. 

Ces commits se font sur la branche hyperlane-master
Si vous ne souhaitez pas garder cette fonctionnalité vous pouvez ajouter un fichier .no-file-watch dans  /vol/site/current/

 

Comment déployer avec le repository

Configuration système

Cette fonctionnalité n'est disponible que si vous avez défini Git en mode de déploiement, onglet DEPLOY.

La configuration est uniquement accessible dans l'environnement de développement, vous ne pouvez pas déployer dans un autre environnement.

 

Configuration de la fonctionnalité

Dans le même onglet, vous pouvez définir l'option de déploiement automatique. Cela vous donne la possibilité de synchroniser votre environnement de développement avec la branche sélectionnée dans l'onglet credentials. Par défaut, c'est master qui est sélectionné.

Chaque fois que vous poussez quelque chose dans votre branche actuellement sélectionnée, un déploiement est effectué. Cela est également vrai s'il y a une validation de demande de fusion (MR) sur la branche.

Dans l'onglet credentials, vous trouverez une liste déroulante avec la liste des branches disponibles dans le repository.

Vous pouvez la mettre à jour quand vous le souhaitez.

 

Étapes du déploiement

Pour déployer quelque chose, vous devez d'abord commit et push quelque chose.

 

Cloner le projet sur votre machine locale

Voici un exemple de l'interface utilisateur. Vous pouvez facilement cloner le projet sur votre machine.

Jetez un œil à la connexion SSH pour faciliter le processus.

 

Utiliser git pour committer et pousser

Voici un exemple de commandes git de base, après des mises à jour de fichiers.

# Add your updates in the index
git add .

# Comment your commit please :thank:
git commit -m "my usefull comment"

# Send your updates into your repository
git push origin my-branch

 

Déployer en développement

Dans le même onglet (DEPLOY), les nouveaux commits (jamais déployés) apparaissent.

Vous devez appuyer sur le bouton DEPLOY NOW pour déployer les nouveaux commits poussés sur la branche. Cela le déploiera dans l'environnement. Cela n'est pas nécessaire si vous avez activé le Déploiement automatique.

🚨 Faites attention, parfois, des mises à jour ont été faites directement sur le serveur (via SFTP, un module, etc.). Dans l'onglet DEPLOY, vous trouverez une nouvelle fenêtre appelée "Unmerged changes detected" dans laquelle vous trouverez les détails des mises à jour (sur une nouvelle branche hyperlane-nom-de-ma-branche ).

Deux options, premièrement, ne l'utilisez pas et effacez les mises à jour avec un nouveau déploiement (forcé), deuxièmement, cliquez sur le bouton "Review and merge" pour obtenir le détail et utilisez le lien GitLab pour accéder à la branche temporaire créée afin de comparer avec la dernière version. Vous pouvez facilement fusionner et déployer.

 

Vérifier que le déploiement a fonctionné correctement

Maintenant, vous devez vérifier dans le déploiement dans l'onglet EVENTS et une nouvelle ligne devrait être présente avec Deploy latest code from Git avec le nom de l'utilisateur qui l'a déployé et la date à laquelle cela s'est produit. Par exemple :

Un déploiement peut échouer, vous devriez être prudent et utiliser la documentation pour le débogage (voir plus bas).

 

Comment fonctionne le déploiement du repository ?

Le déploiement passe par quelques étapes pour s'assurer que tout devrait fonctionner correctement une fois terminé, comme la vérification de la configuration de votre PrestaShop, l'installation des dépendances avec composer et la régénération de son autoload et bien plus encore.

Un déploiement crée un nouveau répertoire de construction dans votre environnement de développement. Il n'écrase pas simplement l'existant.

Si le déploiement est un succès, aucune action n'est requise.

# Go to the approot directory or /vol/site
cd /opt/approot;

# List the builds
ls -la

 

Meilleures pratiques pour le repository

Utiliser un workflow

Comme vous devriez le savoir, il n'est vraiment pas conseillé de travailler directement sur la branche principale (master). La bonne pratique est d'utiliser une nouvelle branche pour développer une nouvelle fonctionnalité, mais vous pouvez aussi aller plus loin avec un flux de travail, une façon de gérer votre travail dans le repository. Sur PS Hosting, nous utilisons Git Flow mais cette façon de travailler n'est pas obligatoire, c'est un exemple concret pour comprendre comment un flux de travail peut fonctionner avec Git.

 

Installer git flow sur votre machine locale

# Linux
apt-get install git-flow

Initialiser git flow

Allez dans le répertoire racine de votre projet.

# This will init the workflow on your current project
git flow init

Quelques questions sont posées sur le nom que vous souhaitez donner à la fonctionnalité, la version (…) vous êtes libre de le configurer comme vous le souhaitez, avec une configuration par défaut ou non.

La configuration par défaut sur git flow :

develop → La branche de référence pour démarrer/terminer une nouvelle fonctionnalité

release → Une version à livrer

master → L'environnement de production

 

Cependant, avec PS Hosting et ses multiples environnements et le repository lié à l'environnement de développement, il serait préférable de le configurer ainsi :

La configuration que vous devriez avoir en tête pour PS Hosting :

develop → La branche de référence pour démarrer/terminer une nouvelle fonctionnalité

release → Une version à livrer

master → L'environnement de développement

 

Exemple simple avec git flow

Le projet est déjà configuré sur votre machine locale (clone git, installation git flow…).

# Go to the right branch
git checkout develop

# Start new feature
git flow feature start my-super-feature

# Live your life (updates files, commit & push)
# ...

# Finish a feature
git flow feature finish my-super-feature

Lisez la documentation officielle et évitez beaucoup d'erreurs.

 

Nettoyer votre serveur des déploiements échoués

Après un déploiement échoué, vous pouvez voir des répertoires de construction qui ne sont pas du tout utilisés. Nous devons les nettoyer avant le prochain clone, après un déploiement réussi. Vous pouvez lister ces constructions ici :

# Go to the approot directory or /vol/site
cd /opt/approot;

# List the builds
ls -la

Les builds en cours d'utilisation sont ceux avec un lien symbolique vers les répertoires current & previous. Deux règles importantes que vous devez garder à l'esprit :

Les répertoires current & previous ne doivent jamais être supprimés ! Jamais.

Ne supprimez pas les répertoires de construction avant que les volumes n'aient été démontés. Jamais.

Pour démonter les volumes, nous les démonterons et les supprimerons un par un. Voici comment faire :

Sélectionnez celui qui n'est lié ni au courant ni au précédent, comme dans cet exemple, la construction "build.20220406-105238-b5f54fe1”

Maintenant, nous devons démonter tout dans "build.20220406-105238-b5f54fe1", nous commençons par lister ce qui est monté :

cat /proc/mounts | grep [build_name]

Vous devriez obtenir quelque chose comme ceci :

Nous devons démonter chaque sous-répertoire répertorié, un par un, avec cette commande :

umount /vol/site/[build_name]/[img|override|....]

Les commandes ressembleront à ceci :

umount /vol/site/build.20220406-105238-b5f54fe1/img;
umount /vol/site/build.20220406-105238-b5f54fe1/upload;
umount /vol/site/build.20220406-105238-b5f54fe1/modules;
umount /vol/site/build.20220406-105238-b5f54fe1/themes;
umount /vol/site/build.20220406-105238-b5f54fe1/translations;
umount /vol/site/build.20220406-105238-b5f54fe1/download;
umount /vol/site/build.20220406-105238-b5f54fe1/vendor;
umount /vol/site/build.20220406-105238-b5f54fe1/override;

Si vous voulez gagner du temps, voici un exemple vide que vous pouvez utiliser, remplacez nom_du_build

# replace build-name by your build name :)
umount /vol/site/build-name/img;
umount /vol/site/build-name/upload;
umount /vol/site/build-name/modules;
umount /vol/site/build-name/themes;
umount /vol/site/build-name/translations;
umount /vol/site/build-name/download;
umount /vol/site/build-name/vendor;
umount /vol/site/build-name/override;

Vérifiez que tout s'est bien déroulé en listant à nouveau :

cat /proc/mounts | grep [build_name]

Le résultat devrait être vide. Vous pouvez maintenant supprimer en toute sécurité le répertoire de construction réel :

rm -rf [build_name]