Развертывания и TFS, общие вопросы

Question

SOX требует, чтобы у нас была отдельная группа для развертывания нашей сети ASP.NET в рабочем состоянии.

В настоящее время эта группа имеет доступ к нашему текущему хранилищу кода в VSS и использует VSS для развертывания кода, который был проверен в VSS.

Как обычно выполняются развертывания для веб-приложений?

Как разработчик, я использовал функцию Deploy в Visual Studio для развертывания кода в сетевой папке, которая соответствует виртуальной папке IS, но я не думаю, что мы можем ожидать, что группа развертывания будет приобретать копию Visual Studio просто для развертывания.

Мы могли бы проверить код в TFS, но какое минимальное программное обеспечение потребуется этой группе для развертывания? Будет ли достаточно клиентского доступа Team Explorer?

Мне известно, что Team System имеет функции для автоматизации создания приложения. Люди обычно внедряются в Production, копируя файлы aspx и dll из среды QA в рабочую среду, или вы обычно развертываете непосредственно из TFS или даже VS? Мне кажется, что предпочтительным подходом было бы развертывание из среды QA, поскольку это среда, которая должна быть одобрена для выпуска, или эти файлы должны быть проверены в TFS и развернуты из TFS, при условии, что вы можете развернуть из TFS .

Что меня смущает, так это то, что бинарные (двоичные) файлы, локальные для проекта, входят в TFS? Разве это не создает проблем для других разработчиков в том смысле, что только 1 разработчик - тот, с проверенным двоичным файлом - может на самом деле отлаживать, потому что для отладки требуется доступ на запись в двоичные файлы? Означает ли это, что двоичные файлы не должны быть проверены в TFS? Но в конечном итоге, если вы развертываете из TFS, двоичные файлы ДОЛЖНЫ быть добавлены в TFS. Они добавлены как отдельный (скомпилированный) узел приложения? Если так, то это звучит ужасно. Я бы предположил, что нет. Как можно убедиться, что двоичные файлы соответствуют исходному коду, который мы помечаем с определенным номером версии?

Очевидно, я невежественен. Может кто-нибудь дать мне общее представление о том, как вы справляетесь с управлением версиями и развертыванием, в частности, с использованием TFS?

Answer 1

Звучит так, будто вы спрашиваете, каковы лучшие практики использования TFS для развертываний. Эта книга от команды TFS должна ответить на большинство ваших вопросов. Большое различие между TFS и VSS заключается в том, что по умолчанию извлечение TFS не блокирует файл от редактирования другим разработчиком. TFS имеет довольно приличную возможность слияния для обработки изменений в одном и том же файле. В книгах TFS это объясняется гораздо подробнее и почему это хорошо.

Что касается обработки двоичных файлов вашего приложения, они обычно должны генерироваться процессом сборки и автоматически развертываться в целевой среде (dev, qa, staging). Сторонние двоичные файлы, от которых зависит ваш код, будут зарегистрированы вместе с исходным кодом, чтобы убедиться, что в процессе сборки есть все необходимые сборки.

Как вы упомянули, развертывание в рабочей среде должно запускаться вручную из qa или промежуточной среды, недоступной разработчикам для соблюдения правил SOX.

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

Answer 2

Одна минимальная возможность (т.е. относительно простая и с использованием свободного программного обеспечения) - это использование скриптов Powershell для компиляции с использованием MSBuild.Для работы с вашим источником контроля вы можете использовать Subversion , который также можно создавать по сценарию.

Я бы посоветовал вам изучить сценарии непрерывной интеграции, чтобы узнать больше о том, что вы спрашиваетео.