Discussion :

[elpaulo]

Bonjour a tous,

Dans ma quête de mettre en place un serveur d'intégration au sein du service informatique de ma boite, je suis bloqué sur un point qui nous parait important.

J'ai bien compris le système d'artefacts de teamcity, et j'arrive à configurer le fait que l'artefact d'un projet "bibliothèque de classes" de visual studio soit le contenu du dossier bin/debug ou release.

Ce qui nous simplifierai grandement la vie, c'est de pouvoir utiliser directement ces artefacts dans nos nouveaux développements .net. Je m'explique :

Actuellement, lorsque l'on démarre un nouveau projet, on crée notre dépôt svn, on crée la solution visual studio à l'intérieur puis, si le besoin s'en fait sentir, nous allons devoir faire référence à une dll créé dans un autre dépot. A partir de la l'enfer démarre, on doit aller chercher le dépot correspondant, récupérer les sources, se demander si la dll est a jour, sinon régénérer la dll depuis les sources, et enfin y faire référence dans notre nouveau projet.

J'ai donc l'impression qu'il nous manque une brique dans le process, a savoir une espèce de référentiels de dlls générées à nous, et je me demandais si teamcity pouvais jouer ce rôle, et si oui, comment ?

Merci d'avance pour vos réponses.

[gboissinot]

Excellente problématique...

Le serveur d'intégration continue JetBreains TeamCity (ou d'autres comme le très célèbre serveur d'intégration continue Hudson) ont un rôle bien défini, c'est-à-dire de lancer une nouvelle instance d'un processus d'intégration continue suite à une modification de ton environement (comme un commit dans l'outil de gestion de configuration logicielle).

Ton processus d'intégration continue comporte une phase de build, consistant à transformer le code source (représentation humaine) en un code binaire (représentation machine). Ce code binaire est ensuite packagé donnant naissance à un ensemble d'artefacts dont certains vont avoir vocation à être des bibliothèques réutilisables.
Ces artefacts ont donc vocation à persister et nécessitent alors d'être stockés dans des dépôts d'artefacts ou repository.
Mais chaque artefact a une identification unique (comme une version). En cas de nouvelle modification de code source, tu auras un nouveau artefact avec donc une nouvelle identification (nouvelle version).

Ce role de repository d'artefacts n'est pas disponible au niveau de ton serveur d'intégration continue (comme TeamCity) mais nécessiste un outillage supplémentaire.

Dans le monde Java, tu as les outils les plus connus actuellement comme Sonatype Nexus, JFrog Artifactory et Apache Archiva (il y a bien sur plein d'autres).
Mais malheureusement, ces outils sont centriques Java et je dirais même centrique Maven (célèbre outil de build et de packaging du monde Java).
Ainsi, si tu veux stocker tes artefacts (qui sont des dll) dans ces outils, cela va être possible mais difficile car il te faudra les Mavenisé pour certains et/ou "Ivysé" (métadata Ivy) pour d'autres comme avec Artifactory.

C'est pourquoi le mieux pour le moment est faire une solution custom.Il te faudra stocker tes artefacts dll générés dans un espace de stockage personnalisé puis éventuellement mettre en place un système additionel de métadonnées.

[jonthevice]

Excellente problématique...

Dans le monde Java, tu as les outils les plus connus actuellement comme Sonatype Nexus, JFrog Artifactory et Apache Archiva (il y a bien sur plein d'autres).
Mais malheureusement, ces outils sont centriques Java et je dirais même centrique Maven (célèbre outil de build et de packaging du monde Java).
Ainsi, si tu veux stocker tes artefacts (qui sont des dll) dans ces outils, cela va être possible mais difficile car il te faudra les Mavenisé pour certains et/ou "Ivysé" (métadata Ivy) pour d'autres comme avec Artifactory.

Je sais que le sujet date un peu mais vu que je suis tombé dessus... je me permet de mettre à jour pour les autres.
Aujourd'hui Nexus et Artifactory propose la gestion des packages nuget.

La principale différence est que Nexus les héberge comme des fichiers opaques alors qu'Artifactory propose les même fonctionnalités que pour des projets java (donc possibilité de rechercher sur les metadata, contrôle des licenses,...).
(j'ai même vu une extension VS pour artifactory qui vient de sortir).

Du coup ce que j'ai mis en place sur projet c'est premièrement une instance Artifactory qui me sert de proxy vers la gallerie officielle nuget.
Dans mes definitions de build (j'utilise TFS) j'ai configuré pour faire du push sur mon repo Artifactory qui se charge donc de stocker mes librairies "nugettisées" et deviennent dispo pour les autres équipes via la nuget gallery (à configurer pour pointer vers l'instance d'Artifactory).

En espérat que ça serve à quelqu'un...