Установка Среды сборки - Используя .NET, Java, Гудзон и рубин - Могла действительно использовать критический анализ

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

Экосистема - логичный:

1. Веб-сайт - asp.net MVC 2, .net 3.5, Visual Studio 2010. IIS 6, Facebook iframe приложение приложения. Это приложение веб-сайта/Facebook использует несколько сервисов. Внутренний поисковый API, внутренний API чтения-записи, Facebook и сервис геолокации IP. Больше деталей о них ниже
2. Внутренний поисковый API - .NET, успокоительная, созданная использующая старая школа .ashx обработчики. API использует lucene и базу данных SQL-сервера негласно. Мой проект не коснется кода lucene, но действительно потенциально касается базы данных и веб-сервисов.
3. внутренний API чтения-записи - Java, успокоительный, работая на Tomcat
4. Веб-сервисы Facebook
5. Сайт насмешки, который эмулирует внутренний API чтения-записи и части API Facebook
6. Гудзон - Модульные тесты выполнений на регистрации, и создают некоторые установщики, которые ведут себя несовместимо.

Экосистема - физический:

Все эти машины могут говорить друг с другом, за исключением Гудзона. Гудзон не видит ни одной из целевых машин. Таким образом, код нужно вытянуть, а не продвинуть. (Вещь безопасности) 1. Веб-сервер - Содержит веб-сайт и API чтения-записи. (Сам API пишет в дублируемую среду SQL-сервера).
2. Поисковый сервер - Здания поисковый API.
3. Hudson Server - не имеет полномочий продвинуть к любой среде. Они должны вытянуть. 4. Сервер Lucene 5. Сервер базы данных

Проблема

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

Эта проблема является сложной далее моим стресс-тестированием. Я должен смочь включить и выключить различные внешние компоненты, так, чтобы я мог эффективно определить масштабируемость каждой части. У меня есть стратегии на месте того, как сделать это для каждой зависимости, но она далее усложняет мою стратегию установки, потому что теперь каждый компонент имеет 2 опции. Ложная версия или реальная версия. Конфигурации везде должны быть обновлены соответственно.

Цели

1. Быстро - я хочу отбросить это от 20-минутного осуществления, когда дела идут отлично к 3-минутному
2. Глупый простой - я хочу сказать среду, что сделать с как можно меньшим количеством команд и не иметь, чтобы помнить, как сшить среды вместе
3. Повторяемый - я хочу, чтобы сценарий был идемпотентом. Своего рода заключение к Глупой Простой вещи.

План до сих пор

Вот то, что я придумал до сих пор, и во что я приехал, ища обратную связь:

1. Используйте новые web.config преобразования VisualStudio, чтобы разрешить легко изменять конфигурации на основе среды. Это решение не действительно достаточно все же. Я оставлю на виду набор web.config для разрешения сайту, выполненному локально, но при развертывании в другом месте, у меня есть целых 6 различных возможных выводов для одной только среды напряжения (из-за насмешек для различных зависимостей), уже не говоря о настройках для напоминания, QA и dev. Каждый из них затем потребовал бы своей собственной установки или установки, которая затем выполнит последующую обработку конфигурации. Таким образом, я в настоящее время склоняюсь только к наличию dev версии и версии, которая преобразовывает ключевые значения конфигурации в рубиновый строковый синтаксис интерполяции. ({#VAR_NAME} вид вещи)
2. Создайте рубиновый сценарий для каждого сервера, который является по существу загружающимся сценарием. То есть это сделает, только загружают код Ruby, который делает 'реальную' работу из Гудзона/подверсии, так, чтобы функциональность сценария могла развиться с приложением, помогая создать сайт в любом моменте времени ссылкой соответствующая версия сценария. Таким образом, короче говоря этот сценарий загружает другой сценарий и выполняет его.
3. 'Реальный' рубиновый сценарий затем примет параметры командной строки, которые описывают, как среда должна посмотреть. Оттуда, 1 конфигурационный файл может использоваться, и рубин загрузит текущие установщики, выполнит их, выполнит последующую обработку конфигурации, перезапустит IIS/Tomcat и начнет любой код установки данных, который необходим.

Так вот именно. Я нахожусь в оперативном уплотнении для протестированного на напряжение этого сайта, таким образом, любая обратная связь, что Вы думаете, могла сократить время, это могло бы взять, будет цениться. Это включает бесстыдный запрос на демонстрационный код Ruby. Я не добрался слишком много далее, чем помещает "Привет Мир".:-) Просто руководство было бы полезно. Это - что-то, для чего Грабли были бы полезны? Как Вы рекомендовали бы мне тесты записи на это животное? (Я использую интерфейсы и платформы автонасмешки для насмешки вещей как запросы HTTP в .NET. С ducktyping кажется, что это могло бы быть легче, но я не знаю, как сказать моему коду использовать поддельную утку в тесте, но реальную на практике),

Спасибо все. Извините за такой такой многоречивый, открытый вопрос.