Synchronisation de projets CruiseControl sur des plates-formes Linux et Windows avec des dépendances

Question

J'ai un ensemble d'applications de plates-formes multiples, certaines applications fonctionnant sous Linux et d'autres sous Windows. Je veux accomplir la construction suivante:

Le serveur L exécute CruiseControl avec le projet A, une application de serveur uniquement Linux. Cela devrait commencer en premier.

Si le projet A construit avec succès, il doit lancer en quelque sorte de ...

Projet B, une application client Windows ne fonctionne que sur le serveur W, avec CruiseControl.NET Project B comprend des tests unitaires qui ont effet final de générer des données dans la base de données du serveur. Le projet B prend environ 10 minutes pour construire et exécuter les tests.

Si le projet B construit avec succès, serveur L, qui attend patiemment, coup d'envoi de projet C, qui contient certains cas de test qui recherchent et valident les entrées de la base de données qui ont été générés par le projet B.

Toutes les idées sur comment je peux y arriver? J'ai trouvé this link, mais il semble viser à construire la même base de code sur plusieurs plates-formes sans dépendances.

Sûrement, quelqu'un doit avoir fait cela à un moment donné?

Answer 1

Avoir le projet A est simple. Dans la phase de publication, écrivez un fichier sur un lecteur réseau. Le projet B peut utiliser le bloc de contrôle de source du système de fichiers pour surveiller le système de fichiers réseau et déclencher une génération basée sur le changement du projet A. Une fois cela fait, il écrit un autre fichier dans le système de fichiers (répertoire différent).

Projet C utilise le contrôle de code source du système de fichiers pour surveiller les changements du Projet B.

Tous assez simple.

Si vous n'avez pas de système de fichiers partagé, vous pouvez également utiliser ftp, scp ou http pour déplacer les fichiers de trigger.

Si vous préférez, vous pouvez déclencher une génération à l'aide des interfaces Web appelées à partir des phases de publication Project A et Project B. Avec les questions dans les commentaires, vous pouvez obtenir des informations sur l'échec du projet B (au moins) de deux manières différentes. L'un serait d'avoir un projet B sous CC qui servait de proxy pour le projet à distance B. Le projet à distance B écrirait un fichier pendant la phase de publication et dans le fichier indique s'il a réussi ou échoué. Le projet proxy-B surveillerait ce fichier et pendant sa phase de "construction" lirait le fichier et passerait ou échouerait en fonction du contenu. Le projet C surveille maintenant le proxy-B en utilisant l'élément BuildStatus de CC.

Une autre façon d'aborder le problème serait de remplacer le projet B sous CC.net avec DistributedBuilder CC qui utilise JavaSpaces pour distribuer builds aux agents distants: http://confluence.public.thoughtworks.org/display/CC/Using+distrib+from+the+CruiseControl+contrib

Dans l'approche distribuée du projet B serait encore exécuté sur le Windows machine mais le DistributedBuilder exécuterait le script à distance, puis ramener les résultats au serveur CC.

Answer 2

Mélangez-vous CruiseControl et CruiseControl.Net? Pour CruiseControl.Configuration réseau uniquement, utilisez simplement Project Trigger.