Conseil d’un ami :
- gitlab n’est pas 100% opensource, ils proposent une édition communautaire limité et la totalité des fonctionnalités est dispo avec la version entreprise, leur modèle économique c’est de brider la version CEE (community) dans pas mal de coin pour te pousser à prendre une licence, perso je trouve que c’est plus un freeware qu’autre chose
- gitlab est pas mal mais honnêtement pour l’avoir beaucoup (vraiment beaucoup) utilisé dans le passé ce n’est pas la meilleur alternative.
Si tu cherche à mettre en place un truc je te conseille fortement de jeter un œil à :
- git –init bare
- Gitea (un exemple ici
- gerrit (un exemple ici)
- jenkins/zuul
Cette stack est un peu plus compliquée à mettre qu’un gitlab, mais c’est très puissant, surtout la partie gerrit qui transcende la manière de faire des revues de code.
Si le code Django / Python n’est pas correct, il y a des méthodes pour améliorer les choses notamment :
- https://nvie.com/posts/a-successful-git-branching-model/
- https://semver.org/
Il est également important de mettre en place un système de « core developer » même au sein d’un projet privé en entreprise, afin de garantir la cohérence des données et l’intégrité de l’historique. En effet, si tout le monde à les droits d’écriture sur tout, ça finira toujours à un moment donné à partir dans tous les sens… L’idée, c’est de donner les droits d’écriture à seulement 2-3 personnes de confiance qui ont un certain niveau et à tous les autres imposer de faire des forks dans leur namespace gitlab et de proposer des merge request (l’équivalent des pull requests avec github). Ainsi, la revue de code est obligatoire et il n’est plus possible de merger du mauvais code… et les développeurs « standard » (sans droits donc) ont juste 2-3 commandes de base à connaître pour bosser avec les autres. Sans ce genre de système cela ne peut pas réellement fonctionner car git à été developpé pour ce mode de fonctionnement (au même titre que svn et d’autres gestionnaire de version) et donc son workflow est idéal dans ce cadre.
Fonctionner comme ça m’a permis de :
- coder un petit robot qui réagissait au merge requests proposé et donc qui checkait tout un tas de choses automatiquement et qui proposait des commandes si les choses n’allaient pas
- responsabiliser les gens de l’équipe en les rendant responsables de leur propre forks
- faire monter en compétence l’équipe qui était ultra frileuse à faire du versionning puis au final à pris goût au truc…
J’ai fais des petites formations au début pour leur expliquer l’intérêt et expliquer la sémantique des changement et qu’il est important de penser ses commits de manière propre. Cela permet :
- dans certains cas de retirer (revert) des bugs complet d’un seul coup,
- de faire du debug de manière automatique sans rien toucher et de trouver les changements responsable d’un bug (git bisect),
- de faire un gain énorme de qualité au final
- d’avoir des historiques clairs avec des messages de commit ayant une réelle plus value (exemple)
- d’automatiser tout un tas d’actions qui vont augmenter la qualité globale du projet et vont réduire les taches inutiles et donc laisser plus de temps pour les trucs fun à faire.
C’est gagnant gagnant, mais au début les gens râlent… il faut juste s’y préparer et avec le temps ils changent d’avis !