Решения для автоматического развертывания в среде разработчиков?

Question

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

1. Разработчики обычно создают веб-приложения, веб-службы и демоны, которые общаются друг с другом через HTTP, сокеты и т. Д.
2. Возможно, у разработчиков не все запущено на их локальном компьютере, но все же им нужно иметь возможность быстро выполнить сквозное тестирование, наведя свой компьютер на среду

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

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

Answer 1

Я бы предложил настроить сервер CI ( Hudson ?) И использовать его для управления всеми развертываниями как на вашем QA, так и на производственных серверах.Это вынуждает вас автоматизировать все аспекты развертывания и гарантирует, что разработчики не будут выполнять специальные перезапуски системы.

Кроме того, я бы посоветовал вам рассмотреть возможность публикации результатов сборки в менеджере репозитория, таком как Nexus,Артефакт или Архива.Таким образом, сценарии развертывания могут извлечь любую версию предыдущей сборки.Использование менеджера репозитория позволит вашей команде QA сертифицировать выпуск перед его развертыванием в рабочей среде.

Наконец, рассмотрим один из появляющихся инструментов автоматизации развертывания.Такие инструменты, как chef , puppet , ControlTier , могут использоваться для дальнейшего контроля версий конфигурации вашей инфраструктуры.

Answer 2

Я согласен с предложением Марка использовать Hudson для автоматизации сборки.Нам показались успешными проекты непрерывного развертывания, использующие Nolio ASAP (http://www.noliosoft.com) для автоматического развертывания приложения после того, как сборка будет готова. Как уже говорилось, chef, puppet и тому подобное хороши для установки и конфигурирования промежуточного программного обеспечения, но когда вам нужнопостоянно выпускать новые версии приложений, лучше подходит платформа, такая как Nolio ASAP, которая ориентирована на приложения.

У вас должны быть лучшие ИТ-специалисты, которые создают и утверждают процессы выпуска приложений, а затем предоставляют интерфейсдля разработчиков, чтобы запустить эти процессы в утвержденных средах.

Answer 3

Непрерывная интеграция не означает непрерывного развертывания. Вы можете скомпилировать / протестировать модуль / и т. Д. Код «непрерывно» в течение дня, не развертывая его, и развертывать только ночью. В любом случае, это хорошая идея - развертывать ночью или по требованию, поскольку люди могут проходить интеграционное тестирование в течение дня и не хотят, чтобы база кода изменилась из-под них.

Подумайте, сколько программного обеспечения могут тестировать разработчики локально? Если много, они не должны постоянно нуждаться в окружающей среде. Если не так много, было бы хорошо настроить макеты / заглушки, чтобы можно было протестировать гораздо больше на локальном сервере. Тогда развернутая среда необходима только для настоящего тестирования интеграции и не требует постоянного обновления в течение дня.