Развертывание biztalk на машинах разработчика / сборки - PullRequest
3 голосов
/ 19 мая 2009

Для каждого приложения BizTalk у нас есть файл setup.bat, который создает приложение BizTalk, создает отбрасывания файлов, создает код, gacs, регистрирует ресурсы, создает порты с использованием vcscripts и применяет привязки. У нас также есть cleanup.bat, который выполняет противоположность setup.bat

Эти сценарии затем запускаются через nant и, наконец, используются cruisecontrol.net. Эти сценарии позволяют нам настроить приложение BizTalk на компьютере с BizTalk и последним загруженным источником и инструментами.

Что делают другие для «начальной загрузки» приложений BizTalk в автоматическом режиме?

Я видел задачи BizTalk nant, они быстрее, чем vbscript?

Настройка. bat работает на нашей сборочной машине BizTalk примерно в 3 раза! Диск, процессор, память, пейджинг - все удобно. Полная сборка / развертывание занимает 2 часа до запуска каких-либо тестов - около 20 приложений BizTalk и разных C # сервисов, пользовательских компонентов. Помимо новой машины или перестройки - наша сборочная машина имеет 4 гигабайта, два гипер-резьбовых ядра и сервер около 5 лет. Есть идеи? Как вы строите машины, как.

Ответы [ 4 ]

3 голосов
/ 19 мая 2009

Майкл Стивенсон написал несколько отличных блогов по автоматическим сборкам BizTalk, посмотрите текст ссылки

Мы использовали утилиту, которую Майк разместил в codeplex, которая создаст скрипт сборки MS для приложения BizTalk - это очень хорошо сработало для нас. Вы можете найти это в текст ссылки

1 голос
/ 27 мая 2009

Существует довольно много решений - Роб Боуман упомянул генератор msbuild Майкла Стивенсона Также в codeplex вы можете найти другой фреймворк Скотта Колестока, Томаса Абрахама и Тима Рэйберна

Есть также незначительное добавление , которое я подписал с Осло, но он не настолько зрелый, как эти два, но он использует задачи SDC , что является хорошей отправной точкой если вы хотите создать собственное решение на основе msbuild.

1 голос
/ 22 мая 2009

Я просто создаю MSI через администратора BizTalk. Я храню информацию о привязке отдельно от MSI, поэтому разработчикам необходимо привязывать порты путем импорта файлов привязки, но это легко.

В случаях, когда сборки должны быть развернуты в gac, я использую командный файл, который запускает gacutil, затем устанавливаю MSI и, наконец, связываю порты.

Этот подход прост в обслуживании и, что более важно, легок для понимания и устранения неисправностей другими.

В связи с тем, что BizTalk является источником ресурсов, сначала посмотрите на SQL Server и убедитесь, что вы ограничиваете его до некоторого разумного объема памяти (он занимает все, что может по умолчанию - обычно это самая доступная память). Одно это изменение имеет существенное значение.

Вам также следует рассмотреть возможность использования только минимального программного обеспечения во время разработки - это означает отключение антивируса или исключение бесполезной проверки каталогов при компиляции и развертывании разработчиками. При разработке решения BizTalk избегайте использования MS Word, Messenger и т. Д. В системах с небольшим объемом ОЗУ (2 ГБ или менее).

На рабочих станциях разработчиков включите архив почтового ящика BizTalk и выполните очистку, как описано здесь:

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

Сохранение базы данных небольшого размера позволяет сэкономить ценное дисковое пространство, что может помочь повысить общую производительность.

1 голос
/ 21 мая 2009

Мы также используем NAnt для нашего развертывания BizTalk. В частности, мы используем комбинацию вызова задач BizTalk NAntContrib (которые начинаются с bts ) и использования задачи <exec> для вызова команды строка btstask.exe напрямую.

На некотором уровне все они используют одну и ту же базовую технологию для связи с сервером BizTalk, поэтому трудно сказать, является ли NAnt быстрее, чем что-то вроде VB.

Я скажу, что по моему опыту BizTalk представляется ресурсом hog . Поскольку это трудно изменить, единственное, что мы контролируем, это количество ресурсов, которые мы ему предоставляем. Поэтому, если сборка занимает слишком много времени и у вас есть время / деньги, бросьте на это больше и хуже аппаратное обеспечение. Как правило, это самый дешевый способ, поскольку время, которое мы, разработчики, затрачиваем на незначительные улучшения времени сборки, может стоить гораздо дороже, чем оборудование. Например, мы заметили, что переход на 8 ГБ памяти может иметь все значение, буквально преобразуя весь опыт.

...