Развертывание
TFS из коробки на самом деле не поддерживает развертывания, ее можно развернуть в одном месте при сборке, которое часто является тестовым сервером (подумайте об управлении лабораторией). В TFS 2012 встроена поддержка развертываний Azure, но они по-прежнему происходят в конце сборки, и артефакты сборки не могут быть автоматически развернуты в новом месте.
Вы можете изменить шаблон сборки, чтобы разрешить выпуск в разных местах, но это все равно будет свежая сборка для каждой среды, а не настоящие бинарные рекламные акции.
Однако TFS имеет понятие качества сборки и фактически запускает события при изменении этого качества. TFS Deployer - это сторонний инструмент, который перехватывает событие изменения качества и может выполнять сценарии PowerShell. Это означает, что с помощью простого изменения значения в раскрывающемся списке вы можете автоматически запустить сценарий, который запускается в любой среде, которую вы хотите. Вы можете настроить список качества сборки (для каждой группы) так, чтобы он представлял собой список сред (dev, uat, staging, production и т. Д.), Для которых сценарий затем определяет, где выпустить конкретную сборку.
VS2012 также имеет несколько приятных улучшений для веб-развертывания, что означает, что конфигурации развертывания хранятся в системе управления версиями вместе с проектом, что теоретически означает, что они будут доступны в папке размещения для использования TFS Deployer.
Я не верю, что TFS хранит историю качества сборки, а это означает, что вы не можете использовать историю качества сборки для ведения списка того, что развернуто в какой среде. Однако вы можете довольно легко записать эту информацию как часть сценария развертывания. Или, по крайней мере, добавьте в сборку настраиваемый узел сводки с информацией о выпуске.
TFS2012 имеет возможность пометить сборку как развернутую как часть функциональности развертывания Azure, вы помечаете сборки tfs deployer как развернут с помощью скрипта, но он не очень полезен.
Octopus Deploy - еще один проект, на который стоит обратить внимание, и его можно использовать вместо TFS Deployer, если ваш шаблон сборки создает пакеты NuGet. Это требует немного большего контроля над производственным оборудованием, поскольку вам необходимо установить агенты в каждой среде для обработки выпусков, но это решает множество других проблем с развертыванием.
Контроль версий
Если у вас есть хороший последовательный способ автоматического выпуска, который люди не обходят, вы можете посмотреть на улучшение шаблона сборки, чтобы внедрить версию сборки или номер набора изменений в качестве версии сборки для всего, что создается как часть этой автоматической сборки. Есть несколько способов сделать это, и множество блог posts и инструменты, чтобы помочь вам в этом.
В качестве альтернативы вы можете просто использовать автоматическое управление версиями сборки ([assembly: AssemblyVersion("1.0.*")]), чтобы указать дату / время, когда произошла сборка, что в итоге выглядит как 1.0.1234.123, где 1234 - это что-то вроде дней с 1 января 2000 года, а 123 - это минуты с полуночи (мой конкретика здесь может быть неправильной).
Если вы развертываете веб-сайты, я настоятельно рекомендую вставить текущую версию сборки где-нибудь в html. Таким образом вы можете проверить, на какой версии работает веб-сайт, без необходимости доступа к каталогу bin. Его также можно добавить как строку запроса к импорту файлов css / js, чтобы гарантировать отсутствие кеширования браузера между версиями.
Мысли
Лично я надеюсь, что Microsoft осознает, что рабочие процессы сборки xaml пытаются сделать слишком много и что они разделяют различные задачи (сборка, тестирование, развертывание ...) на разные части, поддерживающие сценарии. Конечно, этого не произойдет до следующего крупного релиза TFS, который выйдет через несколько лет. Хотя с Team Foundation Service они пытаются выполнять итерацию намного быстрее, поэтому они могут фактически расширить возможности развертывания Azure до чего-то более полезного в ближайшем будущем.
person
Betty
schedule
26.10.2012
