Discussion :

[sekaijin]

Bonjour,

Je regarde en ce moment les outils pour la mise en place d'une forge interne (totalement privée hébergée in situ)
Mais bien sur il y a l'existant.

Aujourd'hui nous avons quelques centaines de petit projets java (projet sans rapport avec le web) dont l'usine est construite autour de
Maven, nexus, jenkins, svn, sonar, mantis.

Nous avons aussi quelque projet web qui utilisent en plus Node, Grunt, Bower
pour l'heure ces projet étant à leur début (mise en place générale) le build n'est pas encore intégré.
nous nous orientons vers une utilisation de maven qui est capable d'utiliser grunt, brower etc sans installation préalable.

Mais voilà qu'on nous demande de proposer un service de forge à l'ensemble du groupe avec des projet en C/C++ et tous autres langages.

Dans ce cadre et pour répondre à des besoins que nous avions déjà nous envisageons de passer à git

Je regarde donc en ce moment gitbucket https://github.com/gitbucket/gitbucket

J'ai trouvé des doc et des outils pour migrer svn vers git
mais je n'ai rien trouvé pour migrer mantis vers gitbuket issue

Enfin ce post pour vous demander s'il existe des image VM (centos chez nous mais pour tester ...) proposant de tester l'association
jenkins gitbuket nexus

Je suis preneur de votre avis sur la solution envisagée.

A+JYT

[Logan Mauzaize]

Pourquoi ne pas simplement intégrer Grunt/Bower et C/C++ dans Jenkins ?

[sekaijin]

pour grunt et bower nous n'en sommes qu'au début
mais le backoffice étant un projet java osgi qui utilise maven
utiliser maven pour tout le projet parait plus naturel que de devoir multiplier les outils.
car du coup un simple mvn install sur le projet parent
et le back se compile et se package pour java
le front se génère et s'assemble avec grunt et bower et war assembly

alors qu'en le faisant à l'extérieur de maven il faut builder d'abord le front avec grunt et bower
s'assurer de les fichier sont bien placé dans la hiérarchie pour qu'ensuite le build maven génère le jar de backoffice et le war du front
en faisant tout passer par maven quelque soit le poste (développeur ou usine jenkins) mvn install fonctionne partout.

sur cette partie c'est un choix que devra faire le projet.
pour le moment nous n'avons pas vu d'avantage particulier à installer sur tous les poste des membres du projet et sur l'usine les outils comme grunt bower etc.
mais s'il y en a une sommes intéressé par l'info.

Quant aux projets C++ pour l'instant nous n'avons pas plus d'info donc il faudra voir.

aujourd'hui ce qui m'importe le plus c'est l'association jenkins/gitbucket
par rapport à aujourd'hui jenckins/svn/mantis
passer à gitbucket nous apporte un ensemble intégré d'outils : git issue wiki
une facilité pour les différentes entités du groupe via l'interface web de crée son projet publier des info et le suivre.

il me faut donc évaluer la solution et le coût de la migration de svn à git et de mantise à gitbucket issue.

merci de ta réaction qui mets le doigt sur des points qu'il faudra aborder.
A+JYT

[Logan Mauzaize]

pour grunt et bower nous n'en sommes qu'au début
mais le backoffice étant un projet java osgi qui utilise maven
utiliser maven pour tout le projet parait plus naturel que de devoir multiplier les outils.
car du coup un simple mvn install sur le projet parent
et le back se compile et se package pour java
le front se génère et s'assemble avec grunt et bower et war assembly

alors qu'en le faisant à l'extérieur de maven il faut builder d'abord le front avec grunt et bower
s'assurer de les fichier sont bien placé dans la hiérarchie pour qu'ensuite le build maven génère le jar de backoffice et le war du front
en faisant tout passer par maven quelque soit le poste (développeur ou usine jenkins) mvn install fonctionne partout.

sur cette partie c'est un choix que devra faire le projet.
pour le moment nous n'avons pas vu d'avantage particulier à installer sur tous les poste des membres du projet et sur l'usine les outils comme grunt bower etc.
mais s'il y en a une sommes intéressé par l'info.

Aucun problème là dessus, nous aussi on se cherche. Mais avec des client de plus en plus indépendant du backoffice, la séparation se fait de plus en plus sentir et surtout cela permet de livrer l'un indépendamment de l'autre.

Je pense que deux arguments doivent être pris en compte : le cycle de vie en développement et celui en déploiement. Après il faudra trouver le compromis qui convient.

Installer grunt / bower s'effectue très simplement dès lors qu'on utilise npm. Qui lui même s'installe très simplement si on a les droits d'admin sinon cela requiert une petite procédure toute simple.

En local tu n'es pas trop censé faire "mvn install". Ton IDE gère normalement tout le cycle de vie et permet de by-pass le repo local. Par exemple avec Eclipse, il créé simplement un faux dépôt interne qui gère les dépendances qui sont liées à un projet.

aujourd'hui ce qui m'importe le plus c'est l'association jenkins/gitbucket
par rapport à aujourd'hui jenckins/svn/mantis
passer à gitbucket nous apporte un ensemble intégré d'outils : git issue wiki
une facilité pour les différentes entités du groupe via l'interface web de crée son projet publier des info et le suivre.

il me faut donc évaluer la solution et le coût de la migration de svn à git et de mantise à gitbucket issue.

merci de ta réaction qui mets le doigt sur des points qu'il faudra aborder.

Je ne connais pas GitBucket. Mais il existe de nombreux outils d'hébergement de projet (SCM + Wiki + Tracker) : Trac, Redmine, les produits Atlassian, CodeBeamer.

Normalement il existe des commandes pour exporter de SVN à Git.