Cet article est le 2ème de la série sur le déploiement et l’intégration continu dans Prestashop. Les autres articles articles de cette série sont les suivants :
Cette étape va surtout vous concerner si vous travaillez en équipe sur les projets et/ou si vous faites intervenir ponctuellement des intervenants externes. Dans le cas ou vous travaillez tout seul, ce n’est pas forcément nécessaire mais c’est tout de même une bonne pratique.
Dans le cadre de mes projets j’ai toujours 3 environnements :
Environnement local
Environnement de préproduction ( branche git dev )
Environnement de production ( branche git master )
Au niveau de git, le workflow utilisé est le suivant :
Toute nouvelle fonctionnalité est faite d’abord en local, dans une nouvelle branche, issue de master. La livraison en préproduction est faite en mergeant cette branche dans la branche dev La livraison en production est faite en mergeant cette branche dans le branche master
Aucun commit n’est donc fait directement ni dans la branche master, ni dans la branche dev.
Partant de ce principe on peut donc définir les branches master et dev comme protégées, et empêcher les développeurs de pousser directement du code dans ces branches. Lors de l’initialisation de notre projet nous avons créé par défaut une branche master.
Nous pouvons donc créer une branche dev si elle n’existe pas encore. Puis la pousser sur le dépôt distant et définir que notre branche suivra la branche dev distante. C’est possible via les commandes suivantes :
git checkout-b dev
git push--set-upstream origin dev
git checkout -b dev
git push --set-upstream origin dev
Nos 2 branches sont bien créés à présent, il est temps d’aller dans gitlab pour configurer ce blocage.
Je pars du principe que votre compte gitlab est en anglais.
Aller dans « Settings / Repository » puis dans « Protected branches ». Normalement la branche master doit déjà être protégée, mais si ce n’est pas le cas configurez le. Puis faites de même sur la branche dev.
Il est également nécessaire de configurer quel rôle est autorisée à merger ou pusher du code. Dans mon cas j’autorise ensuite uniquement les utilisateurs qui ont le rôle « Maintainers » à merger le code, et personne à push.
En fonction de la taille de votre projet et des différents intervenants c’est ici qu’il faudra affiner les droits.
Un lead developpeur aura par exemple le rôle de maintainer sur le projet ce qui permettra à lui seul de livrer du code en production. Mais on peut déjà autoriser les développeurs à livrer à merger leur code en préproduction ( En autorisant le rôle Developer )
Sur un projet personnel, on peut être moins strict et se dire que seule la branche master sera protégée. Ceci simplifiera les livraisons de code. Libre à vous ici de définir vos règles en fonction de la taille de votre équipe et de votre projet 🙂 Mais c’est ici que vous pouvez le définir.
Ceci aura pour effet d’interdire les push de code en direct sur ces branches. Comme vous pouvez le voir sur la capture suivante, si j’essaye d’envoyer du code, le push va générer une erreur :
Livraison de code avec les Merge Request (MR)
A partir de la pour la livraison du code on va utiliser la fonctionnalité de Merge Request de gitlab. ( Si vous avez l’habitude d’utiliser Github le wording change juste légèrement de Pull Request à Merge Request mais c’est exactement la même chose. )
Pour l’exemple nous allons donc créer une nouvelle branche « gitignore » et ajouter les fichiers Thumbs.db dans le fichier .gitignore situé à la racine du projet. Une fois la branche envoyée, vous pouvez tout de suite voir un encart vert en haut de votre dépôt dans l’interface gitlab qui vous demande de faire une merge request. Cliquer sur le bouton « Create a merge request »
Nous allons à présent voir les différentes options de la fenêtre de création de la merge request
La branche dans laquelle vous souhaitez livrer le code. Par défaut ce sera la branche par défaut du projet qui sera sélectionnée. Si vous souhaitez livrer sur l’environnement de préproduction il faut donc bien penser à merger vers « dev »
Mettez un titre qui décrit la modification ( par défaut cela reprends le message du commit )
Mettez une description rapide du changement, ceci permets d’expliquer aux autres intervenants ce qui est réalisé dans cette branche.
(Si nécessaire ) sélectionner la personne qui va devoir vérifier le code
Options qui permettent de supprimer la branche une fois qu’elle est livrée ( bonne pratique pour éviter d’avoir trop de branches sur le projet ) Et de regrouper tous les commits d’une branche en un seul lors de la merge request ( permets d’avoir un historique git plus simple ), sur ce point c’est à votre convenance. De mon côté j’aime bien garder l’historique de tous les commits sur certains développements pour retenir les différentes étapes.
Liste des commits qui vont être livrés
Une fois que tout est bon cliquez sur le bouton « Create Merge Request » 🙂
La merge request est ensuite créé comme vous pouvez le voir sur la capture suivante :
L’onglet important ici est « Changes », puisqu’il permets de vérifier les changements de code qui vont être mis en place. Et des les valider ( ou non ) Dans notre cas d’exemple on peut voir que c’est très basique, mais il peut y avoir des 100 aines de lignes dans cette vue !
Si les changements ne sont pas bons, le reviewer pourra mettre des commentaires et refuser votre Merge Request. Dans ce cas il suffit de pousser du code sur la branche concernée, et la merge request se mettra à jour automatiquement.
Si les changements sont ok, il est temps de cliquer sur le bouton « Merge » de l’onglet « Overview » Et le code sera ensuite bien livré 🙂
A travers ces différentes étapes Il est donc possible de contrôler le code qui va être envoyé vers quel environnement et par qui. Ceci nous permets de répondre à notre première problématique de qui livre du code et ou.
Dans la prochaine étape, on va s’intéresser à vérifier si le code qui est poussé est conforme à la qualité de notre projet. Et que les fichiers envoyés sont valides, toutes ces vérifications vont pouvoir se faire sur les Merge Request (MR), ce qui permettra d’éviter de livrer n’importe quoi 🙂
Articles Relatif à Prestashop : Déploiement continu, qui peut livrer du code et ou
