Я пытаюсь найти лучший способ соединить быстрый, повторяемый, неразрывный процесс сборки для следующей среды. У меня есть план, как это сделать, но я действительно ценю критику. (Я также был бы признателен за пример кода, но об этом позже)
Экосистема - Логическая:
- Сайт - asp.net MVC 2, .net 3.5, Visual Studio 2010. IIS 6, приложение iframe для Facebook
приложение. Этот веб-сайт / приложение Facebook использует несколько сервисов. Внутренний API для поиска, внутренний API для чтения / записи, Facebook и служба геолокации IP. Подробнее об этом ниже
- API для внутреннего поиска - .net, restful, построен с использованием обработчиков старой школы .ashx. API использует lucene и базу данных sql server за кулисами. Мой проект не затронет код lucene, но потенциально касается базы данных и веб-сервисов.
- внутренний API для чтения / записи - Java, restful, работает на Tomcat
- Веб-сервисы Facebook
- Издевательский сайт, который эмулирует внутренний API для чтения / записи и части API Facebook
- Hudson - запускает модульные тесты при регистрации и создает некоторые установщики, которые ведут себя непоследовательно.
Экосистема - Физическая:
Все эти машины могут общаться друг с другом, кроме Хадсона. Хадсон не может видеть ни одну из целевых машин. Таким образом, код должен быть извлечен, а не выдвинут. (Безопасность вещь)
1. Веб-сервер - содержит веб-сайт и API для чтения / записи. (Сам API записывает в реплицированную среду сервера sql).
2. Поисковый сервер - содержит поисковый API.
3. Hudson Server - не имеет разрешений на передачу в любую среду. Они должны тянуть.
4. Lucene Server
5. Сервер базы данных
Проблема
Я пытался настроить этот сайт для работы в стрессовой среде, но количество шагов установки, количество времени, которое требуется для обновления компонента, характер «черного ящика» текущих установщиков и Время, необходимое для генерации данных в тестовую систему, абсолютно разрушает мою производительность. Я настраиваю один параметр, приходится заново развертывать, перезагружать в определенном порядке, сбрасывать некоторые параметры и перестраивать тестовые данные. Ошибки приводят к появлению царапин, а затем в основном к началу. Очень плохо.
Эта проблема еще больше осложняется моим стресс-тестированием. Мне нужно иметь возможность включать и выключать различные внешние компоненты, чтобы я мог эффективно определять масштабируемость каждой части. У меня есть стратегии для того, как это сделать для каждой зависимости, но это еще больше усложняет мою стратегию установки, потому что теперь у каждого компонента есть 2 варианта. Ложная версия или реальная версия. Конфигурации везде должны обновляться соответственно.
Цель
- Быстро - я хочу отбросить это с 20-минутного упражнения, когда все идет отлично, до 3-минутного
- Глупо просто - я хочу сказать окружению, что делать с как можно меньшим количеством команд, и не нужно помнить, как соединять окружения вместе
- Повторяется - я хочу, чтобы скрипт был идемпотентным. Вид следствия Глупой Простой вещи.
План пока что
Вот то, что я до сих пор придумал, и то, что я искал для обратной связи:
- Используйте новые преобразования web.config в VisualStudio, чтобы можно было легко изменять конфиги в зависимости от среды. Это решение не совсем достаточно, хотя. Я оставлю web.config настроенным так, чтобы сайт работал локально, но при развертывании в другом месте у меня есть целых 6 различных выходных данных только для стрессовой среды (из-за насмешек над различными зависимостями), не говоря уже о настройках для Prod, QA и dev. Каждому из них потребуется отдельная настройка или настройка, которая затем обработает конфиги. Поэтому в настоящее время я склоняюсь к тому, чтобы иметь только версию dev и версию, которая преобразует значения конфигурации ключа в синтаксис интерполяции строки ruby. ({#VAR_NAME} что-то вроде)
- Создайте скрипт ruby для каждого сервера, который по сути является скриптом начальной загрузки. Другими словами, он будет делать только загрузку кода ruby, который выполняет «реальную» работу, из hudson / subversion, так что функциональность сценария может развиваться вместе с приложением, что упрощает создание сайта в любой момент времени с помощью Ссылка на соответствующую версию скрипта. Итак, вкратце, этот скрипт загружает другой скрипт и запускает его.
- Затем «настоящий» скрипт ruby будет принимать параметры командной строки, которые описывают, как должна выглядеть среда. Оттуда можно использовать 1 файл конфигурации, и ruby загрузит текущие установщики, запустит их, постобработает конфигурации, перезапустит IIS / Tomcat и удалит любой необходимый код настройки данных.
Вот и все. Я в реальном времени испытываю трудности с проведением стресс-тестирования этого сайта, поэтому любые отзывы, которые, по вашему мнению, могут сократить время, которое может потребоваться, будут оценены. Это включает в себя бесстыдный запрос на пример кода ruby. Я не продвинулся дальше, чем "Hello World". :-) Просто руководство будет полезно. Это то, для чего Rake будет полезен? Как бы вы посоветовали мне написать тесты для этого животного? (Я использую интерфейсы и каркасы автомокинга для макетирования таких вещей, как http-запросы в .net. С ducktyping кажется, что это может быть проще, но я не знаю, как сказать моему коду использовать поддельную утку в тесте, но реальный на практике)
Спасибо всем. Извините за такой долгий, открытый вопрос.