Référence aux artefacts de construction d'un projet svn: external dans un projet .Net

Question

Il s'agit d'une question complémentaire d'une précédente question que j'ai posée .

J'ai maintenant un répertoire / externals à la racine de mon arborescence de projet. À l'intérieur de cela, j'ai une référence à un autre projet. Je suis capable de script la construction de tous mes externes dans le script NAnt du projet principal. Le résultat de ces versions est le suivant:

/ externals / external-project1 / build / buildartifacts / {dlls | html | js}

/ externals / external-project2 / build / buildartifacts / {dlls | html | js}

Tout cela est bien beau, mais je suis maintenant curieux de savoir comment mon projet principal devrait faire référence à ces artefacts de construction. Par exemple, supposons qu'un projet externe génère une DLL dont dépend une partie de ma base de code. Devrais-je simplement référencer la DLL dans le répertoire des artefacts de construction ou dois-je implémenter une autre tâche NAnt qui les copie dans un dossier / thirdparty / libs /?

Cela signifie que ma construction dépend maintenant de la possibilité de construire ce projet externe (qui peut être interne ou tiers). Est-ce une bonne idée de vérifier le dernier jeu d'artefacts de construction pour vous assurer que la construction principale ne se cassera pas à cause des ruptures de générations dépendantes?

J'espère que c'est assez clair. Le simple fait d’écrire cela a au moins clarifié le problème pour moi: -).

- Modifier -

Merci les gars. Je pense que je vais implémenter le "checkout a revision", mais étant donné que les builds sont si rapides, je ne vais pas enregistrer d'artefacts de build. Il va également falloir trouver comment gérer les dépendances du projet externe (par exemple: prototype, swfobject, etc.).

Answer 1

Je dirais de les construire une fois et de vérifier les artefacts de construction dans / public / ext / some_dependency / ref (de toute évidence, le nom de ce dossier vous appartient :-)) et de les référencer à partir de là.

Ma principale raison est qu'il est rarement nécessaire de créer des dépendances externes à chaque fois que vous construisez votre produit. En général, les dépendances externes devraient changer rarement. De plus, vous souhaitez un contrôle strict sur le choix des modifications de dépendance externes afin d'éviter toute instabilité lors de la phase de codage.

En guise d’extension, j’ajouterais une tâche CI distincte qui ne générerait que les dépendances externes et les vérifierait dans le dossier susmentionné sous certaines conditions extérieures - une validation dans le dossier source de la dépendance ou autre chose.

Answer 2

Une de mes recommandations (qui, je pense, vient du livre Pragmatic Version Control de Mike Mason) consiste à faire référence à une révision particulière dans votre rapport externe, afin que vous obteniez toujours la même version de la dépendance externe jusqu'à ce que vous choisissiez explicitement de le remplacer. changez-le.

À ce stade, vous l'avez probablement construit de manière interactive une fois pour vous assurer qu'il fonctionne. Compter sur lui pour construire à chaque fois n'est pas vraiment un problème, ce qui vous évite d'avoir à ajouter une indirection dans vos tâches de construction.

Si vous choisissez d'avoir l'indirection, et que, pour une raison quelconque, la construction échoue sur un serveur externe, il est possible que cela soit oublié car la tâche nante suivante récupèrera le binaire précédent.