Как я могу использовать код развертывания между Lab Management и Release Management

После того, как я только начал использовать Microsoft Release Management, я все больше и больше убеждаюсь, что он не очень подходит для запуска интеграционных тестов. Это может быть ложным ощущением, которое у меня есть, и я хотел бы получить больше информации о это. Когда мы впервые рассматривали это, у меня было намерение запускать тесты, определенные в нашем плане тестирования, через его конвейер, но теперь я вижу, что мы должны запускать их как можно чаще. Мы хотели бы проводить интеграционное тестирование каждую ночь, но наши релиз-кандидаты определяются только в конце спринтов, поэтому использование управления релизами для этого кажется противоречивым.

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

  • конвейер управления релизами должен развертывать наши проекты в QA и рабочей среде.
  • Лабораторный шаблон также должен развернуть проект на нескольких виртуальных машинах для запуска интеграционных тестов.

Для этого Управление релизами использует несколько очень хороших абстракций. Вы можете кодировать области компьютера и определять компоненты на основе структуры папок для размещения, чтобы определить каждую часть всего приложения для развертывания. С другой стороны, рабочий процесс управления лабораторией этого не поддерживает (или, возможно, я просто его упускаю). Стандартный способ заставить работать развертывание для лабораторного тестирования — написать собственный сценарий Power Shell, который перемещает файлы из папки сборки в нужные места, создает пулы приложений для веб-проектов и тому подобное, и все это вручную.

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

Каков правильный подход к максимально возможному совместному использованию кода развертывания между двумя инструментами?


person julealgon    schedule 27.05.2014    source источник


Ответы (1)


Я ожидаю, что в будущем будет улучшена интеграция между RM и MTM/LM. Тем временем вы можете изучить возможность использования Desired State Configuration для обработки единого сценария, который настраивает для вас среды.

Поддержка DSC на самом деле не является готовой в RM Update 2, но RM Update 3 будет иметь встроенную поддержку DSC как для Azure, так и для локальных виртуальных машин. Обновление 3 CTP 1 уже выпущено, но оно еще не готово к производству.

Вы все еще можете использовать DSC из RM в обновлении 2, просто это требует немного больше работы.

person Daniel Mann    schedule 30.05.2014
comment
Никогда не слышал о таком понятии, очень интересно. Вы случайно не из команды разработчиков RM? Можете ли вы поделиться несколькими ссылками о том, как заставить его работать с текущей версией инструмента? - person julealgon; 01.06.2014
comment
@julealgon Я не в команде разработчиков RM, я просто много с ней работаю. Это хорошее место для начала работы с RM/DSC: blogs.msdn.com/b/visualstudioalm/archive/2014/05/22/ - person Daniel Mann; 01.06.2014
comment
Очень мило, я обязательно займусь этим в ближайшие недели. Интересно, есть ли какая-нибудь конкретная статья об использовании DSC внутри Lab Management, какие-нибудь указатели на это? Кроме того, редко можно встретить кого-то, кто широко использовал RM. Не могли бы вы взглянуть на мой связанный вопрос? Я чувствую, что вы могли бы многое рассказать об этом. - person julealgon; 01.06.2014