Непрерывное локальное развертывание TFS

У меня есть настроенный CI с TFS. Каковы наилучшие способы организации развертывания после сборки (а еще лучше после тестирования). Мои бинарники - это некоторые библиотеки с одним исполняемым файлом.

Вот что мне нужно:

  1. Стройте на каждом коммите. (Это настроено и сделано)
  2. Когда сборка прошла успешно (или тесты), загрузите двоичные файлы grep и поместите их в определенную папку на той же машине сборки с полной заменой предыдущих файлов и папок. (Хотелось бы иметь возможность как-то настроить расположение папки)
  3. Запускаю приложение с некоторыми параметрами и мне нужно стандартное перенаправление вывода. Например: App.exe param=paramValue > log.txt
  4. И перед запуском приложения мне нужно убить его предыдущий экземпляр. (Это какой-то экземпляр сервера, который жив все время)

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


tfs continuous-deployment post-build-event
person steavy    schedule 15.03.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Используйте управление выпусками в сочетании с PowerShell (или еще лучше , Конфигурация желаемого состояния). В зависимости от вашей лицензии MSDN, он может быть бесплатным для вас, и он специально разработан с нуля для управления выпусками.

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

Проблема в том, что большинство решений CI (включая TFS) доводят вас до точки, где у вас есть двоичные файлы, а затем говорят: «Ну, вы сами по себе! Получайте удовольствие, выясняя, как развернуть этот материал!» Это никогда не заканчивается хорошо — в итоге вы получаете что-то негибкое и очень сложное в устранении неполадок и обслуживании.

Современный подход «devops» здесь заключается в том, чтобы требования вашего приложения в системе управления версиями рассматривались как код (в данном случае как сценарий или сценарии DSC).

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

person Daniel Mann    schedule 15.03.2015