J'envisage d'écrire mon propre code de livraison à l'aide de Powershell et / ou C #, peut-être bombarder à Nant ou Msbuild.
Contexte (P.S. Ceci est un problème religieux pour certains. Aucune insulte prévue):
Magasin d'une personne, multiples projets exploratoires. Comme la plupart d'entre nous - maintenant Windows et ASP.NET. Considérant mobile et nuage.
J'ai commencé à me mêler de Nant et j'ai essayé de suivre Expert .Net Livraison à l'aide de Nant et Cruisecontrol.net . L'ensemble de la question de "livraison" a été mis sur la glace et il est maintenant temps de "décongeler". Cependant, je ne suis pas sûr de la voie à suivre. De ce que j'ai appris:
Nant montre son âge. C'est maladroit: il est beaucoup plus difficile de comprendre et de maintenir qu'une langue moderne et oo telle que c #. Même après avoir suivi le livre, il semble étrange de travailler dans un environnement arcanique où ce que vous voulez exécuté est XML, et la boucle et la héritage sont (autant que je me souvienne avant que "l'âge de la glace") soit difficile à rendre impossible.
MsBUID est spécifique MS. Je ne suis même pas sûr que cela favoriserait l'environnement non MS. Team Foundation Server est cher.
Même donc, ils semblent en quelque sorte apporter de la valeur parce que sur ma alors rechercher, je n'ai entendu personne d'utiliser leur propre logiciel personnalisé. Cependant, je ne comprends pas pourquoi ne pas utiliser c # et simplement appeler des tâches nant et / ou msbuild au besoin.
Mon conseil est juste à l'inverse - évitez Msbuild comme la peste. Nant est bien plus facile de configurer votre construction pour effectuer des tests automatiques, déployer dans plusieurs environnements de production, s'intégrer à Cruisecontrol pour un environnement d'entrée, intégrer au contrôle de la source. Nous avons traversé tant de douleur avec TFS / MSBUILD (en utilisant TFSDeployer, des scripts personnalisés PowerShell, etc.) pour que cela puisse faire ce que nous avons pu faire avec Nant hors de la boîte. Ne perdez pas votre temps.
Il y a beaucoup plus à construire un produit que de simplement la compiler. Des tâches telles que la création d'installations, la mise à jour des numéros de version, la création d'engrages, la distribution des forfaits finaux, etc. peuvent être beaucoup plus faciles en raison de la fourniture de ces outils (et de leurs extensions). Bien que vous puissiez faire tout cela avec des scripts réguliers, utiliser Nant ou Msbuild vous donner un cadre solide pour faire tout ce
7 Réponses :
Je ne peux voir aucune raison pour ne pas faire un processus de construction simple dans PowerShell.
J'utilise ce qui suit pour mon projet Sandbox: P>
#Types
Add-Type -Path D:\Code\OSLib\SharpSvn-x64\SharpSvn.dll
#Tools
$svn = New-Object SharpSvn.SvnClient
$msbuild = 'D:\Windows\Microsoft.NET\Framework64\v4.0.21006\msbuild'
$mstest = 'D:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest'
#Sandbox
$sandbox = New-Object SharpSvn.SvnUriTarget -argumentlist "http://dan:password@sevenmagoo:81/svn/sandbox/trunk/"
$workingdir = 'D:\Code\sandbox'
$builddir = 'D:\Build\sandbox'
$solution = $builddir + '\sandbox.sln'
$tests = '/testcontainer:D:\Build\sandbox\sandbox.Tests\bin\Debug\sandbox.Tests.dll'
function sandbox() { ii D:\Code\sandbox\sandbox.sln }
function build()
{
echo 'Empty build directory and recreate'
rm -r -Force $builddir | out-null;
md $builddir | out-null;
echo 'Checkout successful? '
$svn.Checkout($sandbox, $builddir);;
echo 'Building'
.$msbuild $solution /nologo;
echo 'Testing'
.$mstest $tests /nologo;;
}
Quel est le point d'emballage des tâches MSBUILD avec un script PowerShell? Il suffit d'utiliser des tâches Msbuild (tonnes de bonnes tâches Msbuild sur mesure) et d'appeler MSBuild directement.
Je l'ai écrit, car j'ai toujours une fenêtre PowerShell Open et je voulais pouvoir construire lors de la commande et exécuter les tests d'unité de projets sans l'ouverture de studio. Gentillesse, dan
Le plus gros problème est la maintenance de vos scripts de construction. Si vous voyez vos projets ou vos environnements restant un peu statiques, il n'y a aucune raison de ne pas encrasser vos propres scripts de construction, d'emballage et de déploiement.
Les choses sont généralement beaucoup plus complexes que vos projets. Certains des avantages MSBUILD, NANT et d'autres produits (commerciaux) sont un support pré-cuit à l'intégration avec des services communs ou des concepts (par exemple, zipping up dossiers) et coûte considérablement moins de temps pour le verser dans votre processus de construction.
Il y aura un coût (réel ou en termes d'effort) afin que vous puissiez raisonnablement prévoir vos besoins d'automatisation, allez dans la direction qui a du sens pour votre environnement.
J'ai ajouté des considérations sur n'importe quelle approche que vous trouvez correspond au mieux ici , ils peuvent aider à déterminer la portée de l'automatisation.
N'utilisez pas C # pour le script de construction, car vous ne voulez pas la compiler lorsque vous vous appuyez sur.
Si vous envisagez d'utiliser PowerShell, jetez un coup d'œil sur PSKE .
Si vous êtes XML sympathique, allez avec Msbuild ou Nant. Peut-être Ceux-ci sont des scripts sont précieux pour vous. Msbuild a un avantage: Ctrl + F5 construit ce script dans Visual Studio.
Je me déplace lentement pour rake car il est gentil et rubis est la langue de programmation (ce qui signifie que vous pouvez faire n'importe quoi): J'ai blogué à quel point cela pourrait être agréable, mais vous devez le traduire ou regarder le code uniquement . Si vous aimez ça, vous voudrez peut-être voir Script complet et dépendances .
À la fin de la journée, les tâches Msbuild et Nant peuvent survenir à la ligne de commande, alors ils sont donc pourraient supporter des trucs non-MS.
Je préférerais Msbuild personnellement et laisserais un serveur de construction comme TeamCity of CCnet faire la construction et le déploiement, etc. Il est incroyable flexible.
+1 pour TeamCity. Nous avons commencé avec CC.NET au travail et passa à TeamCity pour faciliter la maintenance et les fonctionnalités supplémentaires. Nous utilisons toujours Nant derrière les scènes, mais il doit faire beaucoup moins qu'avec cc.net. jetbrains.com/teamcity J'ai toujours du mal à voir comment tout le monde peut préférer écrire un script Msbuild à Un nant, cependant, le premier semble être un clone maladroit de ce dernier.
Il existe un radeau de tâches de Msbuild personnalisées, voir les tâches de la communauté Msbuild, les tâches SDC et le pack d'extension Microsoft Msbuild pour en nommer quelques-uns. La mise en œuvre de votre propre tâche est totalement et totalement triviale - hériter de tâche et implémenter la méthode exécutée (). Je trouve ça un doddle.
Nant en tant que projet est mort, ou sur le soutien de la vie (la dernière version était de 0,86 beta 1, il y a deux ans). C'était essentiellement coupé court par la sortie de Msbuild. Nant était sympa, Msbuild est ok, je suppose que, mais je me sens de plus en plus d'écrire un code dans, eh bien, une langue plutôt que des trucs procéduraux XML. Avec les cadres de construction basés sur XML, l'expérience de débogage est affreuse et vous finissez par tromper en incorporant les "scripts" en C # qui défaitent le but de la déclaration sur la programmation. Même histoire triste que xslt, à cette affaire.
Quelques bonnes cadres de construction sans XML:
J'utilise toujours Msbuild car c'est le format des fichiers CSPROJ, mais pour des trucs spécifiques, la logique de construction de Shun de Shun en XML (aucune tâche MSbuild personnalisée).
Nant peut ne pas être activement entretenu, mais la dernière version fonctionne bien. Je trouve qu'il est significativement plus facile à utiliser que d'écrire un script Msbuild personnalisé. Pour la construction de solutions / projets Visual Studio, je viens de shell (EXEC) à Msbuild de Nant.
Oui, cela fonctionne toujours, mais l'extension est douloureuse et NantContrib a flatliné pendant un moment. Ce qui est nécessaire pour un système de construction est une gestion sensible de la dépendance, de nombreuses tâches personnalisées, un débogage facile et une extensibilité facile. Nant ne fournit que les deux premières fonctionnalités et les tâches personnalisées sont parfois un peu squameuses. Mais si vous avez une configuration de travail de scripts nant, il va bien de le garder tel quel.
Nant est activement développé, voir l'activité Connexion à SourceForge: sourceforge.net/projects / Nant / Développer
Si vous avez l'intention de continuer à être un "magasin d'une personne" et que vos projets sont généralement petits, vous pouvez probablement vous procurer avec le rouleau de votre propre système de construction. Je recommanderais toujours ne pas le faire depuis que l'expérience des environnements de construction couramment utilisés est une bonne chose à avoir sur votre CV.
J'ai écrit un système de construction personnalisé que nous utilisons au travail il y a environ cinq ans pour gérer certaines constructions pluriblement complexes et multi-cibles que nous avons. Nous l'utilisons depuis environ 2003 et nous continuons à l'utiliser. Cependant, j'ai essayé de le déplacer vers la fourmi ou même de faire pour les raisons suivantes:
Maintenant, notre environnement est un peu plus complexe que la plupart puisque nous faisons le développement de systèmes intégrés, il n'est donc pas rare que la construction d'un seul produit soit construite avec deux ou trois chaînes d'outils différentes sur Windows, sur une machine à linux via SSH Pour une cible uniquement Linux, et Psexec sur une machine Windows distante à Utilisez un compilateur bloqué. C'est vraiment assez drôle de regarder en arrière et de penser que le système de construction que nous avons démarré avec un seul fichier de commandes, a été réécrit à l'aide de Perl pour accueillir un mélange de déclarations déclaratives et de relevés de langue de programmation, puis a été écrit à nouveau dans une déclaration XML semblable à celle des fourmis. style qui vole le lot ou la coquille. Maintenant, je pense à remplacer tout cela avec Ant + Maven + Ivy ou une chaîne similaire.
Rouler mon propre système de construction était la bonne décision pour moi à l'époque puisque nous étions une jolie petite boutique faisant des constructions essentiellement basées sur des outils de ligne de commande et il n'y avait pas une large gamme d'outils disponibles à l'époque. Aujourd'hui, cependant, je recommanderais de prendre un bon avis sur les outils disponibles. Après tout, écrire votre propre système de construction signifie que vous passerez du temps et de l'argent écriture et de le maintenir au lieu d'écrire Code de production . .
Il existe de nombreux outils disponibles pour la tâche aujourd'hui qui gèrent presque toutes les idées tordues que vous pouvez trouver. Je pense que le temps consacré à l'apprentissage d'un système existant et à le prolonger pour répondre à vos besoins est probablement plus utile. J'ai trouvé l'expérience d'écrire des tâches de fourmis assez intéressantes. Dans l'ensemble, il s'agissait d'une bonne expérience d'apprentissage, même si je l'ai fait sur un travail contractuel qui a utilisé la fourmi et Cruisecontrol de publier des documents.
Une chose que je n'ai pas encore connue de mentionner jusqu'à présent: dépendance / gestion de la reconstruction. Un bon système de construction (même le vénérable De ce point de vue, je penserais longtemps et difficile avant de rouler votre propre solution.
C'est triste d'entendre que Nant mourait, cependant; Bien qu'il a sa part de verrues, la fourmi est un système de construction raisonnable et flexible. faire ) vous traitera pour vous et si vous construisez votre propre système de construction, vous faites l'une des deux choses:
Merci à tous pour des réponses incroyables - ça va prendre un peu pour digérer, mais je me sens vraiment comme je viens de rencontrer de superbes consultants. J'aimerais pouvoir "accepter" toutes vos réponses! Merci donc pour une si grande plate-forme - tant techniquement que socialement.