Развертывание в гибкой среде - PullRequest
0 голосов
/ 21 января 2009

В прошлом моя команда разработчиков в основном занималась разработкой водопадов на основе существующего приложения, и развертывание было действительно выполнено только к концу выпуска, что обычно приводило к выпускам TEST, UAT, PROD, обычно состоящим только из трех-пяти выпусков в двухмесячном цикле.

Релиз был установщиком MSI, развернутым с помощью групповой политики.

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

Приложение является приложением VB6, и MSI позаботилась о регистрации COM, пользователи не имеют повышенных привилегий на своих компьютерах.

Есть ли у кого-нибудь лучшие решения для быстрого развертывания?

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

Редактировать: Спасибо за предложения. Чтобы уточнить, моя главная проблема в том, что процесс сборки / развертывания MSI занимает много времени, может потребоваться до двух часов, чтобы установить новую сборку на рабочие столы тестировщиков. Тестеры не имеют прав администратора на своей машине (и не получат их), поэтому я ищу лучшее решение.

Я поиграл с ClickOnce, используя упаковщик dot net, который запускает приложение и имеет все сборки OCX / DLL vb6 в виде изолированных зависимостей, но при этом возникают проблемы с поиском всех сборок при запуске или сообщениями на этот эффект.

Ответы [ 9 ]

7 голосов
/ 30 января 2009

CruiseControl и Nant, вероятно, являются лучшим выбором для сборок с гибким выводом. Но быстрое развертывание?

Меня беспокоит то, что вы смотрите на ежедневные сборки неправильно. Ежедневные газеты не должны быть широко развернуты. Фактически, QA и Development - единственные, кто должен заботиться о сборках на ежедневной основе. Даже тогда, разработчики не должны быть не синхронизированы;).

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

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

5 голосов
/ 03 февраля 2009

Это то, что вы можете сделать на виртуальной машине? Вы можете безопасно предоставить своим администраторам права администратора для виртуализированной системы, и большинство программ для виртуализации имеют некоторую форму управления версиями, поэтому вы можете вернуться к «хорошему» состоянию, если что-то пойдет не так. Я нашел, что это очень полезно для тестирования.

1 голос
/ 06 февраля 2009

Если развертывание MSI идет быстрее, чем тестирование Agile, вам следует проверять развертывание MSI менее регулярно.

Используйте развертывание XCOPY везде, где это возможно, используя .local для COM-компонентов. Это может быть проблемой со сторонними компонентами. Поскольку сторонние компоненты довольно стабильны, вы должны иметь возможность создать собственный MSI для них, установить их один раз и покончить с этим.

1 голос
/ 05 февраля 2009

Если я правильно понимаю ваш вопрос, вам необходимы права администратора для установки вашего продукта. Я вижу три варианта:

1) Не устанавливать на рабочие столы тестера. Приобретите некоторые машины для тестирования (как предположил dmo, может помочь VMWare), на которые вы можете безопасно предоставить им права администратора. Это может означать предоставление им тестового домена и их собственной групповой политики для редактирования.

2) Создайте вариант, который не требует установки MSI и может быть выполнен напрямую. Очевидно, что ваши тестеры не будут тестировать процесс развертывания и установки с этим вариантом, но они могут выполнять другие тесты функциональности продукта. Я не знаю, возможно ли это с вашим продуктом; это, безусловно, будет работать.

3) Примите свое быстрое лекарство: «[предпочитайте] реагировать на изменения, а не следовать плану». То есть, если отказ в правах администратора для ваших тестировщиков мешает им эффективно выполнять свою работу, то бросьте вызов организации, чтобы предоставить им права администратора. (по опыту это будет означать переход к # 1, но, возможно, это будет лучший способ сделать это). Если ожидается, что они протестируют продукт, как им вообще не разрешат установить его так же, как покупатель?

1 голос
/ 23 января 2009

Вы можете попробовать COM без регистрации. См. этот другой вопрос . ActiveX EXE все еще должны быть зарегистрированы, хотя.

РЕДАКТИРОВАТЬ: чтобы уточнить, использование COM без регистрации означает, что компоненты OCX / DLL, которые вы упоминаете, не должны быть зарегистрированы. Также нет никаких компонентов OCX / DLL, которые они используют. Вы можете просто скопировать весь каталог приложения на компьютер тестера, и он сразу заработает.

1 голос
/ 21 января 2009

Я бы порекомендовал ClickOnce с возможностью обновления при выполнении. Таким образом, только люди, использующие программное обеспечение, получают и устанавливают обновления.

0 голосов
/ 06 февраля 2009

Я использую SetupBuilder (http://setupbuilder.com/products_setupbuilder_pro.htm) для всех моих сборок. Очень расширяемый. Отличная поддержка.

Не уверен, точно ли он соответствует вашим потребностям, но на форумах такого типа "Установка в качестве пользователя с ограниченными правами (не администратором) на XP" (http://www.lindersoft.com/forums/showthread.php?t=11891&highlight=admin+rights),) мне кажется, что это так.

0 голосов
/ 02 февраля 2009

Я не совсем точно знаю, в чем ваша болевая точка.

  • Вы особо упоминаете регистрацию COM-объектов VB6. Из-за этого иногда не получается установщик?
  • Неужели установщик работает, но люди не знают, как установить новую сборку, поэтому они чаще всего сообщают об ошибках в старой сборке?

Если первое, то я подозреваю, что проблема заключается в том, что VB6 очень вероятно будет играть оборот корзины с фруктами с GUID при перестройке решения. Попробуйте воссоздать ваши публичные интерфейсы в MIDL, и ваши классы VB6 реализуют эти интерфейсы.

Если позже, попробуйте продукт Microsoft SMS . Нет, это не имеет ничего общего с мобильными телефонами. Если все пользователи не находятся в одном домене, вам придется встроить функцию «автоматического обновления» в ваш продукт. Вот предложение третьей стороны , о котором я слышал, но никогда не использовал.

0 голосов
/ 30 января 2009

Вам следует попробовать автоматизированный процесс сборки / развертывания или сценарий, который вы можете запустить вручную. Попробуйте Teamcity или CruiseControl. Удачи!

...