La première fois que je l'ai utilisé, c'était après une petite étude des outils du domaine. Je me rappelle vaguement Trac, pas les autres.
Malgré les bémols qui suivent, j'ai choisi Redmine parce que plus simple à installer et auto-héberger (chez OVH ou à la maison).
Redmine
Petit retour d'expérience sur Redmine, par un type qui est carrément plus codeur qu'adminsys, mais qui s'est retrouvé à gérer de tels outils, au taf ou pour lui-même.
TL;DR : je déconseille s'il faut le garder à jour en permanence. Sauf à être nettement plus versé que moi dans l'admin.
au taf : j'ai géré deux Redmine dans des machines virtuelles sur un serveur OVH pour notre petite équipe.
chez moi : pour mes (tout) petits projets perso, ou pour dépanner quand j'ai filé un coup de main à un pote pour une création de boîte, pareil, machine virtuelle.
Pour toutes ces VM, la Debian du moment, parfois en testing, pour avoir une version un peu plus récente de Redmine.
De base, c'est quasiment aussi simple qu'un apt(-get) install redmine.
Mais ça tire beaucoup de dépendances, dont Ruby on Rails, que je ne maîtrise absolument pas.
Autre problème, surtout si la VM est en Debian testing, une mise à jour, et surtout, un saut de version Debian (ex: 12 - Bookworm vers 13 - Trixie) a tendance à tout casser. C'est pour ça que je déconseille si Redmine doit rester à jour tout le temps.
Git & cie; remarque repo
Redmine gère à peu près tous les gestionnaires de code/version. Le site dit : "SVN, CVS, Git, Mercurial and Bazaar".
Petite remarque concernant git. Je ne sais pas si la proportion d'utilisateur de git connaissant ceci est grande ou petite. Donc je case ça ici "okazou" : pas besoin de GitHub (ou autre) pour avoir un repo centralisé sur un serveur.
Par centralisé, je veux dire : commun à une équipe par exemple, que ce soit en entreprise, ou au quatre coins de la planète.
Un répertoire, un coup de git init --bare, c'est terminé.
Il est possible d'accéder à ce répertoire via ssh, avec une URL du genre ssh://<user>@<serveur>:<port>/path/to/the/repo (git clone ..., git remote ..., etc).
De par ma faible expérience de GitHub, je dirais que :
GitHub crée automatiquement des "pull requests" quand quelqu'un pousse du code (propos à nuancer par des utilisateurs intensifs).
repo "manuel" : en cas de grosse équipe (à partir de 2 !), la rigueur s'impose, essentiellement dans la gestion des branches et de l'intégration, afin que les gens ne se marchent pas sur les pieds.
Mais un repo créé "a la mano" fera aussi bien le boulot.
# Expérience Redmine (limitée)
Posté par pseudonymous . En réponse au message Choix d’un outil pour gérer des projets sur Linux. Évalué à 5.
Avant Redmine
La première fois que je l'ai utilisé, c'était après une petite étude des outils du domaine. Je me rappelle vaguement Trac, pas les autres.
Malgré les bémols qui suivent, j'ai choisi Redmine parce que plus simple à installer et auto-héberger (chez OVH ou à la maison).
Redmine
Petit retour d'expérience sur Redmine, par un type qui est carrément plus codeur qu'adminsys, mais qui s'est retrouvé à gérer de tels outils, au taf ou pour lui-même.
TL;DR : je déconseille s'il faut le garder à jour en permanence. Sauf à être nettement plus versé que moi dans l'admin.
au taf : j'ai géré deux Redmine dans des machines virtuelles sur un serveur OVH pour notre petite équipe.
chez moi : pour mes (tout) petits projets perso, ou pour dépanner quand j'ai filé un coup de main à un pote pour une création de boîte, pareil, machine virtuelle.
Pour toutes ces VM, la Debian du moment, parfois en
testing, pour avoir une version un peu plus récente de Redmine.De base, c'est quasiment aussi simple qu'un
apt(-get) install redmine.Mais ça tire beaucoup de dépendances, dont
Ruby on Rails, que je ne maîtrise absolument pas.Autre problème, surtout si la VM est en Debian
testing, une mise à jour, et surtout, un saut de version Debian (ex: 12 - Bookworm vers 13 - Trixie) a tendance à tout casser. C'est pour ça que je déconseille si Redmine doit rester à jour tout le temps.Git & cie; remarque repo
Redmine gère à peu près tous les gestionnaires de code/version. Le site dit : "SVN, CVS, Git, Mercurial and Bazaar".
Petite remarque concernant git. Je ne sais pas si la proportion d'utilisateur de git connaissant ceci est grande ou petite. Donc je case ça ici "okazou" : pas besoin de GitHub (ou autre) pour avoir un repo centralisé sur un serveur.
Par centralisé, je veux dire : commun à une équipe par exemple, que ce soit en entreprise, ou au quatre coins de la planète.
Un répertoire, un coup de
git init --bare, c'est terminé.Il est possible d'accéder à ce répertoire via ssh, avec une URL du genre
ssh://<user>@<serveur>:<port>/path/to/the/repo(git clone ...,git remote ..., etc).De par ma faible expérience de GitHub, je dirais que :
GitHub crée automatiquement des "pull requests" quand quelqu'un pousse du code (propos à nuancer par des utilisateurs intensifs).
repo "manuel" : en cas de grosse équipe (à partir de 2 !), la rigueur s'impose, essentiellement dans la gestion des branches et de l'intégration, afin que les gens ne se marchent pas sur les pieds.
Mais un repo créé "a la mano" fera aussi bien le boulot.