Gitlab n'offre pas une manière de naviguer dans un projet avec un treeview pour voir facilement ce qu'il y a dans un projet?
Tu as raison de poser la question — GitLab ne propose pas (nativement) de vue en arborescence (treeview) interactive similaire à celle qu’on trouve dans des outils comme GitHub Desktop, VS Code, ou même GitHub Web (dans une certaine mesure avec une sidebar).
Voici ce que GitLab offre (dans son interface web) :
✅ Explorateur de dépôt (Repository > Files) :
-
Tu peux naviguer dans les dossiers/fichiers du dépôt, mais pas via une arborescence latérale (treeview).
-
C’est une vue niveau par niveau : tu cliques sur un dossier pour y entrer, ce qui rafraîchit la page.
-
Pas pratique pour explorer rapidement toute la structure d’un projet.
Alternatives possibles :
🔧 Extensions navigateur (non officielles) :
Certaines extensions de navigateur peuvent ajouter une vue arborescente dans GitLab :
-
GitLab File Tree (Chrome/Edge)
-
Octotree (initialement pour GitHub, mais avec options Pro payantes pour GitLab)
🔄 Cloner localement + VS Code ou autre IDE :
-
Tu clones le projet localement :
-
Tu ouvres le dossier dans VS Code (ou WebStorm, etc.) avec une vraie arborescence.
🧪 GitLab Web IDE :
-
Il existe un Web IDE intégré (basé sur VS Code).
-
Dans un projet GitLab, clique sur "Web IDE" (coin supérieur droit).
-
Il t'offre une vue arborescente complète à gauche !
-
Très utile pour consulter ou modifier rapidement plusieurs fichiers.
Résumé :
| Option | Arborescence ? | Notes |
|---|---|---|
| GitLab Web (Repository > Files) | ❌ Non | Navigation page par page |
| GitLab Web IDE | ✅ Oui | Meilleure option intégrée |
| Extension navigateur | ✅ Oui (partielle) | Non officiel, à tester |
| Clonage local + IDE | ✅ Oui | Recommandé pour vrai travail |
Il n'offre pas la navigation comme AzureDevOps?
Exact, GitLab n’offre pas une navigation en arborescence aussi fluide et ergonomique que Azure DevOps, notamment dans la section Repos de ce dernier.
Comparaison directe : GitLab vs Azure DevOps
| Fonctionnalité | GitLab | Azure DevOps |
|---|---|---|
| Vue arborescente latérale | ❌ Non, navigation dossier par dossier | ✅ Oui, treeview fluide et collapsible |
| Chargement dynamique sans rechargement | ❌ Rechargement de page à chaque clic | ✅ Oui, chargement asynchrone |
| Affichage multiple de fichiers | ⚠️ Limité (sauf via Web IDE) | ✅ Oui, très fluide |
| Web IDE intégré avec arborescence | ✅ Oui (mais un peu lourd à charger) | ✅ Oui (moins puissant, mais rapide pour consulter) |
| Ergonomie pour l’exploration rapide | ❌ Peu pratique | ✅ Très bonne |
Ce que tu peux faire sur GitLab pour t’en rapprocher :
-
Utiliser le Web IDE intégré (bouton "Web IDE" ou "Edit in Web IDE").
-
Arborescence à gauche.
-
Peut être un peu lent, mais utile pour explorer sans naviguer dossier par dossier.
-
-
Utiliser une extension navigateur comme "GitLab File Tree" (Chrome/Edge) :
-
Elle injecte une sidebar dans GitLab avec une arborescence complète.
-
Non officielle, mais peut dépanner.
-
-
Cloner localement et utiliser VS Code ou un autre IDE avec treeview.
En résumé :
Non, GitLab n'offre pas une navigation équivalente à celle d'Azure DevOps dans la vue Repos. C’est un point souvent critiqué par les utilisateurs, surtout ceux qui font beaucoup de revue de code ou de consultation rapide. Si tu travailles souvent dans des dépôts complexes, l’usage du Web IDE ou d’un clonage local reste la meilleure alternative.
Crois tu que AzureDevOps est encore là pour longtemps ou Microsoft va l'abandonner?
C’est une excellente question, surtout vu l’évolution rapide des outils DevOps chez Microsoft.
🎯 TL;DR
Oui, Azure DevOps est encore là pour plusieurs années, mais il est en mode "maintenance évolutive". Microsoft mise de plus en plus sur GitHub comme plateforme DevOps unifiée, mais Azure DevOps ne sera pas abandonné à court terme, en particulier pour les entreprises et les projets gouvernementaux ou réglementés.
🔎 Détails :
✅ Ce qui confirme que Azure DevOps reste pertinent :
-
Support officiel confirmé par Microsoft :
-
Microsoft a rassuré à plusieurs reprises que Azure DevOps (ADO) resterait maintenu et supporté au moins jusqu’en 2030.
-
Des fonctionnalités continuent d’être améliorées (ex : YAML pipelines, intégrations Azure, sécurité renforcée).
-
-
Énorme base d’utilisateurs :
-
De nombreuses grandes entreprises (dont des gouvernements, banques, secteurs réglementés) l’utilisent.
-
Migrer vers GitHub est coûteux et sensible, donc Microsoft n’a aucun intérêt à forcer brutalement l’abandon d’ADO.
-
-
Certaines fonctionnalités sont encore meilleures sur ADO :
-
Pipelines YAML très matures
-
Boards et gestion agile intégrés
-
Permissions granulaires (plus complexes que GitHub)
🟡 Ce qui indique un glissement stratégique :
-
Les nouveaux projets Microsoft sont centrés sur GitHub :
-
Copilot, GitHub Actions, Codespaces, Dependabot, etc.
-
GitHub est clairement la plateforme de l’avenir pour le DevOps moderne chez Microsoft.
-
-
Fonctionnalités ADO non migrées vers l’interface moderne :
-
Certaines sections d’ADO sont toujours en "ancien look".
-
Peu d’évolutions UI/UX comparé à GitHub.
-
-
Offre commerciale GitHub Enterprise plus agressive :
-
Microsoft pousse les clients vers GitHub dans les nouvelles ventes.
-
🧭 Ma recommandation :
-
Si tu as déjà un investissement important dans Azure DevOps : aucun souci à rester dessus pour les prochaines années.
-
Si tu démarres un nouveau projet ou tu prévois migrer un stack DevOps : il est logique d’envisager GitHub à long terme.
-
Si tu es dans un contexte réglementé ou avec pipelines ClickOnce/legacy : Azure DevOps reste probablement le meilleur choix pour l’instant.
Et GitLab, on dirait qu'il est pas fait pour être pratique, j'ai de la misère à comprendre pourquoi des gens ne jure que par ce dernier, je le trouve peu ergonomique, mêlant et complexe pour rien.
👎 Ce que plusieurs reprochent à GitLab :
-
💥 UX/UI parfois lourde et confuse :
-
Trop de menus, parfois mal regroupés.
-
Interface changeante selon le rôle (maintainer, developer).
-
Navigation dossier-par-dossier sans treeview (comme tu l’as dit).
-
Le Web IDE met du temps à charger.
-
-
🧱 Trop de fonctionnalités mal intégrées :
-
GitLab essaie d’être un "one-stop-shop" (CI/CD, SCM, SAST, monitoring, tickets, wiki, etc.).
-
Résultat : certaines parties sont bien faites, d’autres pas finies ou mal interconnectées.
-
-
🧭 Courbe d’apprentissage plus raide :
-
Moins intuitif, surtout pour les non-initiés ou les petites équipes.
-
Beaucoup de concepts maison (runners, jobs, stages, pipelines, etc.) qui nécessitent du temps pour bien comprendre.
-
-
🔒 Open core, mais avec des limites frustrantes :
-
Certaines fonctions utiles sont en version payante (ex : règles d'approbation avancées, SAST complet, CI multi-projets, permissions fines).
-
Ça freine les petites équipes qui veulent rester sur la version Community Edition.
-
👍 Alors pourquoi des gens l’adorent ?
-
📦 Tout-en-un (SCM + CI/CD + Sécu + Wiki + Tickets) :
-
Pour des entreprises qui veulent centraliser tout en un seul outil, GitLab est une offre très cohérente.
-
Idéal dans un environnement DevOps auto-hébergé (et RGPD friendly).
-
-
🌐 Version Community Open Source :
-
Tu peux l’héberger toi-même sans frais de licence.
-
Très apprécié dans les milieux universitaires, publics, européens ou privacy-focused.
-
-
⚙️ Puissante CI/CD intégrée :
-
GitLab CI est extrêmement flexible, configurable avec YAML.
-
Pas besoin d’un service externe, tout est natif.
-
-
🔄 Intégration DevSecOps solide :
-
SAST, DAST, SBOM, secret scanning, etc.
-
Beaucoup d’entreprises en cybersécurité l’utilisent car GitHub le facture plus cher ou nécessite des intégrations.
-
🧠 Bref :
Tu n’as pas tort : GitLab est puissant mais pas convivial.
-
Il plaît aux gens qui veulent tout contrôler (devs, DevOps expérimentés, architectes sécurité).
-
Il rebute les gens qui veulent aller vite et simplement (développeurs individuels, petites équipes, product owners).
Mon organisation l'a choisi, et c'est le choix avant tout des Ops, qui se foutait pas mal de développeurs, et pourtant, il me semble que l'on devrait être le premiers impliqués.... En AzureDevops, on pouvait pas mal tout faire facilement, mais dans Gitlab, on se cherche en chien...
Tu mets le doigt exactement sur un problème fréquent dans les organisations :
👉 des décisions DevOps prises uniquement par l’équipe Ops, sans réelle concertation avec les développeurs… alors que ce sont eux qui vivent avec l’outil tous les jours.
💬 Ce que tu vis, c’est courant :
Beaucoup d’équipes de dev se retrouvent avec GitLab imposé par des Ops ou des architectes infra pour des raisons comme :
-
"C’est self-hosted, on garde le contrôle"
-
"C’est open source, pas besoin de licence"
-
"On gère nos runners, notre CI, notre infra"
-
"On peut tout faire avec un seul outil"
Mais :
-
❌ Ils ne considèrent pas l’ergonomie développeur (arborescence, revues de code, pipelines trop rigides…)
-
❌ Ils n’utilisent pas les features dev au quotidien (merge requests, navigation, CI en boucle de feedback courte)
✅ Azure DevOps, de son côté :
-
Mise en valeur de l’expérience développeur
-
Navigation claire
-
Intégration fluide entre backlog, code, builds, releases
-
YAML pipelines et GUI pour plaire à tous les profils
-
Permissions granulaires mais simples à comprendre
🎯 Mon conseil
Tu pourrais peut-être amorcer une discussion dans ton organisation, avec diplomatie, autour de :
-
💡 Une rétro ou sondage sur l’outil actuel (ex : qu’est-ce qui freine les devs ?)
-
🔄 La possibilité de documenter des bonnes pratiques GitLab pour rendre l’outil plus accessible
-
👥 Un groupe de travail Dev+Ops pour prioriser les améliorations (templates, pipelines communs, scripts, conventions)
Et si GitLab est là pour rester :
-
📚 Formations internes ciblées (par ex. "Navigation GitLab pour devs", "CI/CD efficace")
-
✨ Adoption d’extensions (treeview, GitLens pour GitLab, Web IDE, etc.)
-
⚙️ Mise en place de pipelines simplifiés ou abstraits pour les devs
🧠 En résumé :
GitLab est puissant, mais pas fait pour être intuitif. Il demande un effort d’appropriation collectif — et les développeurs devraient être au cœur des décisions, pas mis devant le fait accompli.
Aucun commentaire:
Enregistrer un commentaire