Configuration initiale<\/h2>\n\n\n\n
Cette \u00e9tape va surtout vous concerner si vous travaillez en \u00e9quipe 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\u00e9ment n\u00e9cessaire mais c’est tout de m\u00eame une bonne pratique.<\/p>\n
Dans le cadre de mes projets j’ai toujours 3 environnements :<\/p>\n
- \n
- Environnement local<\/li>\n
- Environnement de pr\u00e9production ( branche git dev )<\/li>\n
- Environnement de production ( branche git master )<\/li>\n<\/ol>\n
Au niveau de git, le workflow utilis\u00e9 est le suivant :<\/p>\n
Toute nouvelle fonctionnalit\u00e9 est faite d’abord en local, dans une nouvelle branche, issue de master.
La livraison en pr\u00e9production<\/strong> est faite en mergeant cette branche dans la branche dev<\/strong>
La livraison en production<\/strong> est faite en mergeant cette branche dans le branche master<\/strong><\/p>\nAucun commit n’est donc fait directement ni dans la branche master, ni dans la branche dev.<\/strong><\/p>\n
Partant de ce principe on peut donc d\u00e9finir les branches master<\/strong> et dev<\/strong> comme prot\u00e9g\u00e9es, et emp\u00eacher les d\u00e9veloppeurs de pousser directement du code dans ces branches.
Lors de l’initialisation de notre projet nous avons cr\u00e9\u00e9 par d\u00e9faut une branche master.<\/strong>
Nous pouvons donc cr\u00e9er une branche dev<\/strong> si elle n’existe pas encore.
Puis la pousser sur le d\u00e9p\u00f4t distant et d\u00e9finir que notre branche suivra la branche dev distante.
C’est possible via les commandes suivantes :<\/p>\n\n\n\n\ngit checkout -b dev\ngit push --set-upstream origin dev\n<\/pre>\n\n\n\n
Nos 2 branches sont bien cr\u00e9\u00e9s \u00e0 pr\u00e9sent, il est temps d’aller dans gitlab pour configurer ce blocage.
Je pars du principe que votre compte gitlab est en anglais.
Aller dans \u00ab\u00a0Settings \/ Repository \u00a0\u00bb puis dans \u00ab\u00a0Protected branches\u00a0\u00bb.
Normalement la branche master doit d\u00e9j\u00e0 \u00eatre prot\u00e9g\u00e9e, mais si ce n’est pas le cas configurez le.
Puis faites de m\u00eame sur la branche dev.<\/p>\nIl est \u00e9galement n\u00e9cessaire de configurer quel r\u00f4le est autoris\u00e9e \u00e0 merger ou pusher du code.
Dans mon cas j’autorise ensuite uniquement les utilisateurs qui ont le r\u00f4le \u00ab\u00a0Maintainers\u00a0\u00bb \u00e0 merger le code, et personne \u00e0 push.
En fonction de la taille de votre projet et des diff\u00e9rents intervenants c’est ici qu’il faudra affiner les droits.<\/p>\nUn lead developpeur aura par exemple le r\u00f4le de maintainer sur le projet ce qui permettra \u00e0 lui seul de livrer du code en production.
Mais on peut d\u00e9j\u00e0 autoriser les d\u00e9veloppeurs \u00e0 livrer \u00e0 merger leur code en pr\u00e9production ( En autorisant le r\u00f4le Developer )
Sur un projet personnel, on peut \u00eatre moins strict et se dire que seule la branche master sera prot\u00e9g\u00e9e.
Ceci simplifiera les livraisons de code.
Libre \u00e0 vous ici de d\u00e9finir vos r\u00e8gles en fonction de la taille de votre \u00e9quipe et de votre projet \ud83d\ude42
Mais c’est ici que vous pouvez le d\u00e9finir.
Pour toute question sur les r\u00f4les, vous pouvez lire la documentation officielle de gitlab sur les diff\u00e9rents r\u00f4les : https:\/\/docs.gitlab.com\/ee\/user\/permissions.html<\/a><\/p>\n\n\n\n![\"Droits](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-1024x392.png\")
<\/a><\/figure>\n\n\n\nCeci 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\u00e9n\u00e9rer une erreur :<\/p>\n\n\n\n![\"\"](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-1.png\")
<\/a><\/figure>\n\n\n\nLivraison de code avec les Merge Request (MR)<\/h2>\n\n\n\n
A partir de la pour la livraison du code on va utiliser la fonctionnalit\u00e9 de Merge Request de gitlab.
( Si vous avez l’habitude d’utiliser Github le wording change juste l\u00e9g\u00e8rement de Pull Request \u00e0 Merge Request mais c’est exactement la m\u00eame chose. )
Pour l’exemple nous allons donc cr\u00e9er une nouvelle branche \u00ab\u00a0gitignore\u00a0\u00bb et ajouter les fichiers Thumbs.db dans le fichier .gitignore situ\u00e9 \u00e0 la racine du projet.
Une fois la branche envoy\u00e9e, vous pouvez tout de suite voir un encart vert en haut de votre d\u00e9p\u00f4t dans l’interface gitlab qui vous demande de faire une merge request.
Cliquer sur le bouton \u00ab\u00a0Create a merge request\u00a0\u00bb<\/p>\n\n\n\n![\"\"](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-3.png\")
<\/a><\/figure>\n\n\n\nNous allons \u00e0 pr\u00e9sent voir les diff\u00e9rentes options de la fen\u00eatre de cr\u00e9ation de la merge request<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-4.png\")
<\/a><\/figure>\n\n\n\n- \n
- La branche dans laquelle vous souhaitez livrer le code. Par d\u00e9faut ce sera la branche par d\u00e9faut du projet qui sera s\u00e9lectionn\u00e9e.
Si vous souhaitez livrer sur l’environnement de pr\u00e9production il faut donc bien penser \u00e0 merger vers \u00ab\u00a0dev\u00a0\u00bb<\/li>\n - Mettez un titre qui d\u00e9crit la modification ( par d\u00e9faut cela reprends le message du commit )<\/li>\n
- Mettez une description rapide du changement, ceci permets d’expliquer aux autres intervenants ce qui est r\u00e9alis\u00e9 dans cette branche.<\/li>\n<\/ol>\n\n\n\n
![\"\"](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-5.png\")
<\/a><\/figure>\n\n\n\n- \n
- (Si n\u00e9cessaire ) s\u00e9lectionner la personne qui va devoir v\u00e9rifier le code<\/li>\n
- Options qui permettent de supprimer la branche une fois qu’elle est livr\u00e9e ( bonne pratique pour \u00e9viter 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 \u00e0 votre convenance.
De mon c\u00f4t\u00e9 j’aime bien garder l’historique de tous les commits sur certains d\u00e9veloppements pour retenir les diff\u00e9rentes \u00e9tapes.<\/li>\n - Liste des commits qui vont \u00eatre livr\u00e9s<\/li>\n
- Une fois que tout est bon cliquez sur le bouton \u00ab\u00a0Create Merge Request\u00a0\u00bb \ud83d\ude42<\/li>\n<\/ol>\n
La merge request est ensuite cr\u00e9\u00e9 comme vous pouvez le voir sur la capture suivante :<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-6-1024x508.png\")
<\/a><\/figure>\n\n\n\n
- La branche dans laquelle vous souhaitez livrer le code. Par d\u00e9faut ce sera la branche par d\u00e9faut du projet qui sera s\u00e9lectionn\u00e9e.
![\"\"](\"https:\/\/www.h-hennes.fr\/blog\/wp-content\/uploads\/2023\/09\/image-7.png\")
<\/a><\/figure>\n\n\n\n