Déploiement de biztalk sur les machines de développement/build

Question

Pour l'application BizTalk eaach, nous avons un fichier setup.bat qui crée l'application BizTalk, crée des fichiers supprimés, génère du code, gacs, enregistre des ressources, crée des ports -using vcscripts- et applique des liaisons. Nous avons aussi un fichier cleanup.bat qui effectue le contraire de setup.bat

Ces scripts sont ensuite lancés via nant, et finalement utilisés par cruisecontrol.net. Ces scripts nous permettent d'installer une application BizTalk sur une machine avec BizTalk et la dernière source et les outils téléchargés.

Que font les autres pour "amorcer" les applications BizTalk d'une manière répétable et automatisée?

J'ai vu des tâches BizTalk nant, sont-elles plus rapides que vbscript?

La configuration. bat fonctionne plus lentement sur notre machine de construction BizTalk par un facteur d'environ 3! Le disque, le processeur, la mémoire, la pagination sont tous confortables. Un build/deploy complet prend 2 heures avant que les tests ne soient exécutés - environ 20 applications BizTalk et des services C# assortis, des composants personnalisés. Mis à part une nouvelle machine, ou reconstruire - notre machine de construction a 4 Go de RAM, deux cœurs hyper threaded et environ 5 ans de serveur - Des idées? Comment construisez-vous des machines?

Answer 1

Michael Stephenson a écrit quelques grands blogs sur BizTalk automatisé builds, jetez un oeil à link text

Nous avons utilisé un utilitaire qui Mike affecté à CodePlex qui va créer un script MS construire pour une application BizTalk - cela a fonctionné très bien pour nous. Vous pouvez trouver ceci à link text

Answer 2

Nous utilisons également NAnt pour notre déploiement BizTalk. Plus précisément, nous utilisons une combinaison de l'appel BizTalk related NAntContrib tasks (qui commencent tous par bts) et en utilisant la tâche <exec> pour appeler directement la ligne de commande btstask.exe. À un certain niveau, ils utilisent tous la même technologie sous-jacente pour communiquer avec le serveur BizTalk, il est donc difficile de dire si NAnt est plus rapide que quelque chose comme VB.

Je dirai que dans mon expérience BizTalk semble être une ressource hog. Comme il est difficile de changer cela, la seule chose que nous contrôlons, c'est la quantité de ressources que nous leur donnons. Par conséquent, si les builds prennent trop de temps, et que l'on a le temps et l'argent de le faire, lancez le plus gros et le plus mauvais hardware. C'est généralement le moyen le moins cher, car le temps que les développeurs mettent à faire des améliorations marginales pour construire des temps peut coûter plus cher que le matériel. Par exemple, nous avons remarqué que passer à 8 Go de mémoire peut faire toute la différence, transformant littéralement toute l'expérience.

Answer 3

Je viens de créer un fichier MSI via l'administrateur BizTalk. Je garde mes informations de liaison séparées du MSI, les développeurs doivent donc lier les ports en important les fichiers de liaison, mais c'est facile.

Dans les cas où les assemblages doivent être déployés dans le gac, j'utilise un fichier batch qui exécute gacutil, puis installe le MSI et enfin lie les ports.

Cette approche est facile à maintenir et, surtout, facile à comprendre et à résoudre pour les autres. En ce qui concerne BizTalk étant un serveur de ressources, regardez d'abord SQL Server et assurez-vous que vous le limitez à une quantité raisonnable de mémoire (il prend tout ce qu'il peut par défaut - qui est généralement la mémoire la plus disponible).Ce seul changement fait une différence significative.

Vous devez également envisager de n'utiliser qu'un logiciel minimal au cours du développement, c'est-à-dire de désactiver l'analyse antivirus ou l'exclusion des répertoires lors de la compilation et du déploiement des développeurs. Évitez d'utiliser MS Word, Messenger, etc sur les systèmes qui ont peu de RAM (2 Go ou moins) lors du développement d'une solution BizTalk.

Sur les postes de travail des développeurs, activez l'archive messagebox BizTalk et du travail de purge comme expliqué ici:

http://msdn.microsoft.com/en-us/library/aa560754.aspx

Garder petit la base de données permet d'économiser l'espace disque qui peut contribuer à améliorer la performance globale.

Answer 4

Il y a bien quelques solutions là-bas - Rob Bowman a mentionné Michael Stephenson msbuild generator également sur CodePlex, vous trouverez cadre another par Scott Colestock, Thomas Abraham et Tim Rayburn

Il y a aussi un addition mineur par moi palying avec Oslo, mais ce n'est pas la moitié aussi mature que ces deux, mais il utilise le SDC tasks, ce qui est un excellent point de départ si vous souhaitez créer votre propre solution basée sur msbuild.