5

Ce que je cherche à faire est d'avoir CI et une construction automatisée pour toutes mes branches dans un référentiel. Je voudrais que chaque build de ces applications web ait son propre projet et soit placé comme répertoire virtuel (ou équivalent) sur un site de branche. Ce serait génial de pouvoir créer une nouvelle branche et de démarrer automatiquement le processus d'intégration et de construction. L'ajout d'un nouveau répertoire virtuel dans IIS n'est pas une grosse affaire, je suis d'accord pour le faire si le reste se met en place.Constructions automatisées de branches avec SVN

Par exemple:

http://branch.domain.com/branch101/

http://branch.domain.com/otherBranchName/

Actuellement, je suis en utilisant SVN, et Nant CruiseControl.Net, mais je suis ouvert un autre serveur d'intégration continue ou construire scripting si la situation l'exige.

+0

Je ne suis pas certain d'avoir compris la question - recherchez-vous un nouveau projet CC.net à créer automatiquement lorsque vous branchez le code?- ou simplement la meilleure façon de configurer ccnet pour construire plusieurs branches - vous parlez de répertoire virtuel - parlons-nous d'applications web? – Richard

+0

Oui aux deux, j'ai modifié la question pour être plus clair (j'espère!) –

Répondre

1

Je ne comprends pas la vraie question. En tout cas je te suggère Hudson (http://hudson-ci.org/).

C'est facile à utiliser. Il est facile de configurer avec des fichiers XML. Il a l'API à distance.

+0

+1 pour Hudson. (Attention cependant: Si vous construisez sur plusieurs plateformes, Hudson ne passera pas à la prochaine build tant que toutes les plateformes ne seront pas terminées, ce qui signifie que la machine de test/construction la plus lente ralentira tout le monde. quand nous l'avons essayé.) – sbi

+0

Etes-vous sûr? Pour la plate-forme voulez-vous dire emploi hudson? Parce que vous pouvez définir plus d'un "Build Executor". Je ne l'utilise jamais, mais Hudson supporte le mode "maître/esclave" pour distribuer les builds. –

+0

@ungarida: Hudson était l'un des outils CI les plus prometteurs que nous avons évalués et ISTR l'a abandonné pour cette raison. Mais je ne me souviens même pas de ce que sont les «emplois» pour Hudson, donc je suppose que cela veut dire non, je ne suis pas sûr. – sbi

1

Je ne pense pas ce que vous voulez en ce qui concerne la configuration automatique de vos projets d'intégration continue basée sur la branche. Cependant, si vos branches sont assez standard et ne changent pas de façon drastique, il serait plutôt facile d'écrire un script PowerShell (ou n'importe quelle langue de script que vous préférez) pour configurer les nouveaux projets.

Je remets en question le besoin cependant, quand nous branchons dans CC.NET cela prend moins d'une minute pour copier les projets de troncs et rechercher et remplacer les champs nécessaires. Le seul moment où nous rencontrons des problèmes est lorsque nous avons des scripts personnalisés utilisés pendant la construction, si ceux-ci existent, nous devons les modifier aussi, mais cela arrivera avec n'importe quel système d'intégration continue.

3

Cela peut être fait, mais beaucoup de choses dépendront de vos scripts de construction. Si vous indiquez à cc.net de surveiller le dossier svn de niveau supérieur, vous avez par exemple un moniteur de projet:

http://myserver.com/svn/project plutôt que http://myserver.com/svn/project/trunk. Si des modifications sont visibles dans http://myserver.com/svn/project, une build sera lancée. Maintenant, c'est à votre script de construction de déterminer quelle source est obsolète ou s'il y a une nouvelle branche à construire. Le script de construction créerait un nouveau VDir pour toutes les nouvelles branches. Une autre option serait d'avoir un projet cc.net qui a été conçu pour ne rien faire d'autre que d'ajouter de nouveaux projets à votre cc.net. (Appelez le projet BranchBuilder) Je tirerais parti du pré-processeur dans cc.net et d'un fichier .config de haut niveau qui incluait juste le projet pour le tronc et chaque branche. Le projet de création de branche monitory le chemin racine sur svn. S'il voyait des changements, il verrait s'il y avait de nouvelles branches depuis la dernière construction. S'il y en avait un, il pourrait créer un fichier ccnet-branchname.config pour cette branche, créer le vdir puis mettre à jour le fichier racine ccnet.config avec un include supplémentaire. Après la mise à jour de ccnet config, cc.net reconnaîtra que le fichier de configuration a été modifié et rechargera la config en ajoutant votre nouveau projet de branche. Ce projet de branche commencerait à fonctionner et à construire votre nouvelle branche.

+0

C'est, à mon avis, une très mauvaise idée. Je pense que vous automatisez beaucoup trop. Combien de problèmes pourrait-il y avoir à ajouter un bloc au fichier ccnet.config par rapport à cette solution? –

+1

Nous le faisons à la main aussi. Ce n'est pas parce que tu peux faire quelque chose que tu devrais le faire. Cependant, il effectuera la construction automatisée pour la fonctionnalité de branche demandée par le PO. Cela dit, je ne sais pas à quelle fréquence ils se branchent. Cela pourrait être des dizaines de fois par jour. Les ordinateurs sont conçus pour effectuer des tâches répétitives, n'est-ce pas? – PilotBob

+1

@JoshKodroff Je pense que c'est une question d'opinion, "branchement" coûteux est une raison pour laquelle beaucoup de développement se blobbed ensemble dans une ligne (risque croissant). Avoir à se connecter à une machine pour reconfigurer le processus de construction semble comme cela ajoute un coût important à la branche. –

Questions connexes