Bonjour,
Quel est le meilleur outil pour gérer le versionning d’un projet JAVA (une équipe de 5 développeurs).
J’ai entendu parler de Bitbucket, GitLab, GitHub…!
Merci :slight_smile:
Bonjour,
Ca va dépendre de plusieurs paramètres :
- Sur quels outils êtes-vous à l’aise ?
- Quels sont vos besoins en dehors du versionning du code (Intégration continue, issues, etc.) ?
Pour moi, les trois plateformes sont bonnes. La différence se joue surtout sur l’ergonomie et l’intégration des autres applications. Je ne dirai pas qu’une est meilleure que l’autre.
1 « J'aime »
Bonjour,
Je n’ai pas encore essayé ces outils.
L’objectif est de découper le projet en sous-projet, et chaque membre travaillera sur un seul projet.
C’est possible après de fusionner les sous-projets en un seul projet (au niveau du serveur).
Merci !
Avec aussi peu d’information, je ne peux pas conseiller plus un outil qu’un autre.
Pour la gestion de projets et sous-projets, les trois permettent de le faire selon le mode d’organisation (≈groupe) et projet dans l’organisation.
Par contre, la notion de fusionner les projets ne m’est pas clair ici. 🤔 Fusionner d’un point de vue repository ? Maven (ou gradle ou autre système de build) ? Autre ?
Le seul conseil que je pourrai donner avec ces informations, c’est si vos projets sont open source, les mettre sur Github pour des raisons de visibilité.
Merci !
En fait chaque développeur travaille sur un module…Le but est de donner accès seulement aux fichiers de son module.
Non, ce n’est pas un projet open source !
Je suis d’accord avec kneelnrise sur le fait que les outils son similaire, à l’exception du fait que bitbucket est intégré en autre à JIRA qui est populaire dans le monde Java. A propos de JIRA, en tant que dev j’en est aussi entendu du mal donc faudrais d’abord investiguer si c’est vraiment le cas que JIRA est bien.
L’avantage de GitLab c’est que tu peux l’héberger chez toi.
1 « J'aime »
Merci Amirouche ! je pense entre GitLab et bitbucket y a pas une grande différence !
Bonjour Mehdi,
Voici ma stack : JavaScript (Vanilla.js / Harmony.js / Node.js), HTML et CSS.
Pour avoir tester Subversion/TFS (Système de version centralisé) et Git (Système de version distribué) : je me tourne vers Git.
L’avantage incontestable est que la quasis totalité des actions s’effectuent en local et que le projet est exploitable depuis n’importe quelle source serveur. Qui peut le plus pouvant le moins, tu peux te contenter d’une utilisation mono-serveur.
Pour avoir tester les 3 plateformes suivantes sous Git : Github, Gitlab et Bitbucket et les 3 « communautés » qui vont avec : Github est mon premier choix loin devant.
Si ton projet n’est pas OpenSource, tu n’auras pas de plan gratuit sur Github, tu peux donc l’évincer si tu ne souhaites pas investir de l’argent dans ton outil de versionning.
Cependant Github offre énormément d’outil user-friendly pour te mettre à comprendre Git et énormément de ressources.
Ensuite si je devais faire un choix entre Gitlab et Bitbucket je pencherais pour Bitbucket, mais là j’ai pas de raison vraiment pertinente à avancer :D, juste une préférence.
Pour débuter avec Git et comprendre son avantage face à TFS ou SVN je te propose cette lecture :
Bonne chance à toi et ta team !
2 « J'aime »
Pour info, il est possible d’intégrer git à TFS ^^
C’est ce que j’utilise actuellement pour une équipe de 5 développeurs.
L’intérêt de TFS, c’est la gestion des tâches de développement, l’intérêt de git c’est la gestion des sources.
Dans mon cas, je travaille en environnement Microsoft, l’intérêt de TFS est donc son intégration au reste de mon environnement de développement (Visual studio …).
Après, prendre TFS pour utiliser juste Git (ou juste pour sa version de projet, n’est pas à mon avis le choix le plus simple. Un gitLab en auto hébergé, est beaucoup plus souple.
Après, pour Mehdi, sauf si tu n’as pas confiance dans tes devs, je partirais sur un dépôt global pour l’ensemble de ton projet … et j’envisagerais la mise en place de sous-module (c’'est supporté par git) au besoin. Par contre, je ne partirais pas sur une solution de multiple dépôt (alors que tu demandes déjà comment centralisé). C’est aller devant pas mal d’ennuis.
3 « J'aime »
En outil, git. Il est techniquement très bien, et énormément de développeurs l’ont déjà utilisé (vu l’importance de GitHub).
En serveur pour gérer tes dépôts de code, si tu veux du SaaS github est très bien (idem que pour git, la plupart connaissent déjà l’interface). Si tu veux l’héberger toi-même, j’ai entendu du bien de gitlab.
1 « J'aime »
Bonjour Haresis,
Merci pour ce partage de votre expérience avec les outils de versionning.
Notre projet n’est pas open source, la piste GitHub à éliminer. Je partage avec vous notre orientation vers GiT.
Mon plus grand souci est la synchronisation et le tracking des développements.
Maintenant chaque développeur travaille dans son propre coin (en local sur sa machine). Après un certain temps je récupère les fichiers source, je les mets à jour , j’extrait le .war et je l’upload sur un serveur cloud.
Je veux voir les modifications en temps réel afin que je puisse tester et valider les features développés.
Quelle démarche vous me conseillez à suivre, et quelles sont les étapes, les procédures afin de mettre en place des outils fiables de suivi afin d’améliorer la productivité de l’équipe.
Merci
Bonjour Marc,
Merci pour ces précieux conseils !
TFS est un très bon outil afin de suivre l’avancement des dév et du projet. GIT & TFS se complètent.
Le projet est constitué de trois modules. Le but c’est que chaque développeur a accès à son module, et qu’il puisse remonter les développements en temps réel sur un serveur Cloud afin d’assurer le suivi.
En même temps je dois avoir accès à l’ensemble du projet.
Si j’ai bien compris on crée un dépôt global qui contient tous les modules du projet, et je crée des branches par module , et le développeur ne peut accéder qu’aux fichiers source de sa branche.
Merci !!
Bonjour Xavier,
Git est très puissant ! Je pense on va héberger GitLab. Avez-vous la procédure afin de mettre en place Git & GitLab ?
Merci !
Attention, tu confond branche et module.
La branche reprend l’intégralité de ton dépôt alors que le module permet de découper ton projet en module, sous module.
Voici une doc sur ce sujet :
https://git-scm.com/book/fr/v1/Utilitaires-Git-Sous-modules
pour le moment, je n’ai pas encore tester le couple module et TFS, j’arrive à faire sans.
1 « J'aime »
⚠ Github permet aussi d’avoir des repositories privés ! Ce que j’avais dit, c’est si vous voulez vous tourner vers l’open source, c’est surement le meilleur des outils proposé. Mais si vous souhaitez rester en repositories privés, c’est tout à fait aussi acceptable !
Un moyen assez simple de voir quel outil vous irait le mieux serait de les tester. Faîtes-vous un projet simple qui peut être open-source (le même, pour bien voir la différence) et essayez de faire un processus complet.
Exemple:
- Créer une tâche, la compléter, l’affecter, etc.
- Faire le dev dessus (peut être un copier/coller pour les trois projets, votre fonctionnement local ne change pas)
- commit/push
- Pull-request (revue de code, commentaire, réponse commentaire)
- Merge
- Fermeture ticket (peut être en automatique selon les raccourcis des différents projets, ex:
resolves #xxxpour Github) - Autres
Ça peut vous prendre une journée tous à le faire, mais au moins, vous aurez déjà fait un premier choix et normalement pas n’importe lequel. Vous n’êtes que 6 (si je compte bien), donc autant profiter de cette souplesse pour décider ensemble.
⇨ Ceci parce que les trois outils ont une version gratuite (même si open source) que vous pouvez essayer. Je parle bien sûr des fonctionnalités de base, mais vous pouvez aussi voir les outils plugable dessus et cie. pour limiter encore plus votre choix par la suite.
Et pour info, Gitlab accepte aussi des projets privés hébergés sur leurs serveurs pour des petites équipes (voir cependant les conditions).
1 « J'aime »
Merci Marc pour l’article !
Mais on peut construire plusieurs branches ? et chaque branche sera exploitée par un développeur afin d’accéder à ses codes source.
Je confond aussi git & gitlab ? quelles étapes dois-je procéder pour la mise en place de l’outil de versionning ?
Installation de Git sur le serveur ?
Installation de GitLab sur le serveur ?
Installation de Gitlab sur les machines locales ?
Y a une config ?
Merci !
Bonjour Mehdi,
Vous allez voir, passer de simples fichiers à l’utilisation de git va changer votre vie (en bien!). Par contre, attention, la mise en place de l’utilisation d’un tel outil dans une équipe de 6 personnes est nettement plus compliquée que juste suivre une procédure d’installation…
Il va falloir potentiellement:
- administrer votre serveur
- définir votre (vos) dépots
- choisir votre process de développement à plusieurs (branches ou forks ou multi-repo/modules)
- l’intégrer à votre processus/outil de déploiement
- apprendre à votre équipe à l’utiliser (et en particulier à gérer les conflits de version)
- vérifier que l’outil est bien utilisé :)
- réparer les inévitables erreurs
Je vous conseille de vous documenter (Google est votre ami, chercher autour de git, flow, branch, tutorial,…), voire de trouver quelqu’un qui peut vous aider (dans un meetup, un ami, un dev de votre équipe qui fait de l’open source, ou un freelance/consultant externe)
Et commencez le plus simple possible:
- faites un unique dépôt
- hébergez-le en privé chez gitlab (39 euros/an) ou github (plus cher).
- et mettez-y le code du plus petit module possible
Bon courage!
1 « J'aime »
Mon plus grand souci est la synchronisation et le tracking des développements.
Maintenant chaque développeur travaille dans son propre coin (en local sur sa machine). Après un certain temps je récupère les fichiers source, je les mets à jour , j’extrait le .war et je l’upload sur un serveur cloud.
Je veux voir les modifications en temps réel afin que je puisse tester et valider les features développés.
Quelle démarche vous me conseillez à suivre, et quelles sont les étapes, les procédures afin de mettre en place des outils fiables de suivi afin d’améliorer la productivité de l’équipe.
Pour ma part, je vois deux manière d’aborder la chose.
Soit chacun travail avec sa propre réplique (« fork ») de votre dépôt (« repository ») principal. Soit chacun travail sur une branche (« branch ») séparées sur ce même dépôt (on en parlera plus loin, c’est plus simple mais moins optimal).
D’expérience, pour conserver un dépôt principal propre, il vaut mieux que les branches des développeurs soit faites sur une réplique. Mais ce que j’entends par propre c’est que les branches du dépôt principale soit toutes dans un état valide (et pas que certaine d’entre elle soient « en cours de développement »).
Je vous laisserai adapter ça avec BitBucket ou Gitlab mais si j’avais dû faire cela avec Git + Github, voici le processus que j’aurai mis en place.
Imaginons que ma société s’appel Weyland S.A.R.L. et que le projet s’appel Prometeus, je crée une Organisation « Weyland » et je crée un dépôt nommé « Prometeus ». Par défaut, la branche de se dépôt sera nommé « master » et son serveur source sera identifié comme étant « origin ».
Depuis le serveur j’ai donc la branche (orga/repo/:branch) weyland/prometeus:master. Personne ne peut travailler sur cette branche. Sa seule utilité est d’être rapatriée sur votre serveur de prod pour extraire votre .war.
Vous créez une copie conforme de « master » appelée « develop » : weyland/prometeus:develop sur votre serveur. C’est cette branche qui sera utilisé pour faire des tests globaux sur un environnement de pré-production (que ce soit en local ou via un serveur de pré-prod). Ici vous allez pouvoir vous assurer que tout le travail effectué par les collègues est fonctionnel, testez l’intégralité des tests cases, lancez les tests unitaires, voir si tout passe, etc, etc.
Si tout vous semble correcte et que rien n’a regressé dans « develop » au moment du test, vous faites une fusion (« merge ») en utilisant « master » comme destination et « develop » comme source. Une fois la manœuvre effectué, « master » est à jour vis à vis de « develop ».
Au fur et à mesure que votre produit se « versionne », vous dupliquez la branche de votre « master » afin que votre dépôt « weyland/prometeus » ressemble à quelque chose comme ça
weyland/prometeus
- master
- develop
- version-2.x
- version-1.x
Maintenant pour changer le dépôt en apportant du code de vos développeurs, ça va se passer sur des répliques.
Chacun de vos collaborateurs à son propre compte.
Ainsi si je dois ajouter une nouvelle fonctionnalité à « develop », je mets à jour ma réplique en créant une nouvelle branche bob/prometeus:my_new_feature depuis weyland/prometeus:develop.
Sur bob/prometeus:my_new_feature, je suis le roi du pétrôle ! Je fais ce que je veux, je pete tout, je fais des conneries (je veux dire je peux le faire c’est pas grave, l’important sera de les réparer haha).
Quand mon taff est fini sur la feature, je fais une demande de fusion (« pull request ») de bob/prometeus:my_new_feature vers weyland/prometeus:develop. Et c’est la que les outils de Github sont top (et que je n’ai pas assez d’expérience sur Bitbucket ou Gitlab).
Mais normalement vous êtes tous à même de voir ligne par ligne ce qui a bougé, de le commenter, dans faire des reviews, de bloquer la pull request, de la tagguer, de la fermer, de la ré-ouvrir, de demander à avoir des frittes avant de faire passer la PR (« pull request ») bref, c’est là que le travail de relecture de code, vérification des tests unitaires (y en a t-il assez ?), question de clarification, ajout de commentaire, etc. se fait. C’est le grand filtre au spagetti code. Tout ce qui passe de bob/prometeus:my_new_feature vers weyland/prometeus:develop est propre au terme de ce processus dont le temps ne peut malheureusement pas être estimé précisément et que donc beaucoup d’entreprise choisissent de mettre de côté… malheur !
- Les développeurs n’apprennent pas de leurs erreurs, ne s’intéressent pas aux autres codes, etc etc « pour gagner du temps » et on se retrouve avec une solution vraiment merdique, on finit par perdre du temps plus le produit se complexifie et devient crade, et les devs ne se rendent pas service et reste sur leur acquis. C’est là que le vrai travail pour s’améliorer commence. L’idée ici ce n’est pas de blamer le développeur mais de l’aider à uniformiser son code, les tests etc. On s’aperçoit qu’au file du temps, tout le monde s’améliore et les PR sont de plus en plus courtes et pertinentes. Via se processus vous pouvez tous vous mettre d’accord sur des bonnes pratiques en faisant référence à d’autre PR, d’autres personnes, tout est traqué et là pour servir de support ! C’est grandiose.
Si la PR est accepté, le code est reversé dans « develop », c’est testé sur environnement de pré-prod, approuvé etc. et ça passe sur « master » direction la production.
Une variante de ça est de tout faire « dans le même dépôt » sans faire de réplique par développeur. Ça « simplifie » virtuellement le processus car au final le dépôt principal ressemble à ça
weyland/prometeus
- fix_bug_566
- master
- bug-fix-agenda
- …
- …
- …
- develop
- fix_bug_567
- version-2.x
- …
- …
- …
- feature_x
- version-1.x
- …
- …
- …
- …
- …
avec des branches qui sont déjà dans « develop » mais pas fermé (alors que si elles sont pas fermés dans des réplique, fondamentalement sa regarde le développeur en question), d’autre non, donc certaines sont bonnes à effacée, d’autre non et personne ne peut faire ce travail fautes de processus simple pour savoir à qui est quoi.
En déportant les branches de travail sur des répliques, tout ceci se gère via les PR qui offrent (en tout cas pour Github) toute la panoplie d’outil pour créer un projet solide, péren (pérenne huhu), divisible, etc.
Divisible car effectivement rien ne vous empêche de créer une réplique weyland/prometeus-2.x:master, weyland/prometeus-2.x:develop et d’appliquer le même type de procédé à vos anciennes versions qu’il faudra supporter pour les hotfix de sécurité ou le support client, etc.
En espérant vous avoir fourni des pistes de travail.
Bon courage !