Si vous suivez mes recommandations ci-dessous (je l'ai depuis des années), vous pourrez:
- placez chaque projet n'importe où dans le contrôle de code source, tant que vous conservez la structure du répertoire racine du projet vers le bas
- construire chaque projet n'importe où sur n'importe quelle machine, avec un minimum de risque et une préparation minimale
- construire chaque projet complètement autonome, tant que vous avez accès à ses dépendances binaires (répertoires "bibliothèque" et "sortie" locaux)
- construire et travailler avec n'importe quelle combinaison de projets, car ils sont indépendants
- construire et travailler avec plusieurs copies / versions d'un même projet, car elles sont indépendantes
- évitez d'encombrer votre référentiel de contrôle de source avec des fichiers ou des bibliothèques générés
Je recommande (voici le boeuf):
Définissez chaque projet pour produire un seul livrable principal, tel qu'un .DLL, .EXE ou .JAR (par défaut avec Visual Studio).
Structurez chaque projet comme une arborescence de répertoires avec une seule racine.
Créez un script de construction automatisé pour chaque projet dans son répertoire racine qui le construira à partir de zéro, sans aucune dépendance sur un IDE (mais ne l'empêchez pas d'être construit dans l'EDI, si possible).
Envisagez des projets nAnt pour .NET sous Windows, ou quelque chose de similaire en fonction de votre système d'exploitation, de votre plate-forme cible, etc.
Faites en sorte que chaque script de construction de projet fasse référence à ses dépendances externes (tierces) à partir d'un seul répertoire de "bibliothèque" partagé local, avec chaque binaire COMPLÈTEMENT identifié par la version: %DirLibraryRoot%\ComponentA-1.2.3.4.dll
, %DirLibraryRoot%\ComponentB-5.6.7.8.dll
.
Faites en sorte que chaque script de génération de projet publie le livrable principal dans un seul répertoire de "sortie" partagé local: %DirOutputRoot%\ProjectA-9.10.11.12.dll
, %DirOutputRoot%\ProjectB-13.14.15.16.exe
.
Faites en sorte que chaque script de construction de projet fasse référence à ses dépendances via des chemins absolus configurables et entièrement versionnés (voir ci-dessus) dans les répertoires "bibliothèque" et "sortie", ET NON O AILLEURS.
Ne laissez JAMAIS un projet référencer directement un autre projet ou l'un de ses contenus - n'autorisez que les références aux principaux livrables dans le répertoire "output" (voir ci-dessus).
Faites de chaque script de compilation du projet référence à ses outils de construction requis par un chemin absolu configurable et entièrement versionné: %DirToolRoot%\ToolA\1.2.3.4
, %DirToolRoot%\ToolB\5.6.7.8
.
Faire tous les projets de construction de contenu source de référence de script par un chemin absolu par rapport au répertoire racine du projet: ${project.base.dir}/src
, ${project.base.dir}/tst
(syntaxe varie selon outil de build).
TOUJOURS exiger qu'un script de construction de projet fasse référence à CHAQUE fichier ou répertoire via un chemin absolu et configurable (enraciné dans un répertoire spécifié par une variable configurable): ${project.base.dir}/some/dirs
ou ${env.Variable}/other/dir
.
NE JAMAIS autoriser un script de génération de projet à référencer QUELQUE CHOSE avec un chemin relatif tel que .\some\dirs\here
ou ..\some\more\dirs
, TOUJOURS utiliser des chemins absolus.
NE JAMAIS autoriser un script de construction de projet à référencer QUELQUE CHOSE en utilisant un chemin absolu qui n'a pas de répertoire racine configurable, comme C:\some\dirs\here
ou \\server\share\more\stuff\there
.
Pour chaque répertoire racine configurable référencé par un script de génération de projet, définissez une variable d'environnement qui sera utilisée pour ces références.
Essayez de réduire le nombre de variables d'environnement que vous devez créer pour configurer chaque machine.
Sur chaque machine, créez un script shell qui définit les variables d'environnement nécessaires, qui sont spécifiques à CETTE machine (et éventuellement spécifiques à cet utilisateur, le cas échéant).
Ne placez PAS le script shell de configuration spécifique à la machine dans le contrôle de code source; à la place, pour chaque projet, validez une copie du script dans le répertoire racine du projet en tant que modèle.
EXIGEZ que chaque script de génération de projet vérifie chacune de ses variables d'environnement et abandonne avec un message significatif si elles ne sont pas définies.
EXIGEZ que chaque script de construction de projet vérifie chacun de ses exécutables d'outil de construction dépendants, les fichiers de bibliothèque externes et les fichiers livrables de projet dépendants, et abandonne avec un message significatif si ces fichiers n'existent pas.
RÉSISTEZ à la tentation de valider TOUS les fichiers générés dans le contrôle de code source - pas de livrables de projet, pas de source générée, pas de documents générés, etc.
Si vous utilisez un IDE, générez les fichiers de contrôle de projet que vous pouvez et ne les validez pas dans le contrôle de code source (cela inclut les fichiers de projet Visual Studio).
Établissez un serveur avec une copie officielle de toutes les bibliothèques et outils externes, à copier / installer sur les postes de travail des développeurs et à construire des machines. Sauvegardez-le, avec votre référentiel de contrôle de source.
Établissez un serveur d'intégration continue (build machine) sans aucun outil de développement.
Envisagez un outil pour gérer vos bibliothèques externes et vos livrables, comme Ivy (utilisé avec Ant).
N'utilisez PAS Maven - cela vous rendra d'abord heureux et finira par vous faire pleurer.
Notez que rien de tout cela n'est spécifique à Subversion, et que la plupart d'entre eux sont génériques pour les projets ciblés sur n'importe quel système d'exploitation, matériel, plate-forme, langage, etc. J'ai utilisé un peu de syntaxe spécifique au système d'exploitation et à l'outil, mais uniquement à titre d'illustration. -J'espère que vous traduirez vers votre système d'exploitation ou l'outil de votre choix.
Note supplémentaire concernant les solutions Visual Studio: ne les mettez pas dans le contrôle de code source! Avec cette approche, vous n'en avez pas du tout besoin ou vous pouvez les générer (tout comme les fichiers de projet Visual Studio). Cependant, je trouve préférable de laisser les fichiers de solution aux développeurs individuels pour qu'ils les créent / les utilisent comme ils l'entendent (mais pas archivés dans le contrôle de code source). Je garde un Rob.sln
fichier sur mon poste de travail à partir duquel je référence mon (mes) projet (s) en cours. Étant donné que mes projets sont tous autonomes, je peux ajouter / supprimer des projets à volonté (cela signifie qu'aucune référence de dépendance basée sur un projet).
Veuillez ne pas utiliser d'externes Subversion (ou similaires dans d'autres outils), ils sont un anti-pattern et, par conséquent, inutiles.
Lorsque vous implémentez l'intégration continue, ou même si vous souhaitez simplement automatiser le processus de publication, créez un script pour celle-ci. Créez un script shell unique qui: prend les paramètres du nom du projet (comme indiqué dans le référentiel) et du nom de la balise, crée un répertoire temporaire dans un répertoire racine configurable, extrait la source pour le nom de projet et le nom de balise donnés (en construisant le URL appropriée dans le cas de Subversion) vers ce répertoire temporaire, effectue une compilation propre qui exécute les tests et conditionne le livrable. Ce script shell doit fonctionner sur n'importe quel projet et doit être archivé dans le contrôle de code source dans le cadre de votre projet "outils de construction". Votre serveur d'intégration continue peut utiliser ce script comme base pour la création de projets, ou il peut même le fournir (mais vous pouvez toujours vouloir le vôtre).
@VonC: Vous ne voulez PAS travailler à tout moment avec "ant.jar" plutôt qu'avec "ant-abcdjar" après avoir été brûlé lorsque votre script de construction est interrompu parce que vous l'avez exécuté sans le savoir avec une version incompatible de Ant. Ceci est particulièrement courant entre Ant 1.6.5 et 1.7.0. En généralisant, vous voulez TOUJOURS savoir quelle version spécifique de CHAQUE composant est utilisée, y compris votre plate-forme (Java ABCD) et votre outil de construction (Ant EFGH). Sinon, vous rencontrerez éventuellement un bogue et votre premier gros problème sera de savoir quelles versions de vos différents composants sont impliquées. Il vaut simplement mieux résoudre ce problème dès le départ.