Стратегия управления сайтом больших ресурсов в TFS

Question

Я занимаюсь миграцией ряда сайтов, которые ранее управлялись по существу без контроля версий (там был подключен VSS к серверу разработки, но из POV разработчика это было по существу несуществующий) к TFS с WebDeploy, установленным на машине Windows Server 2012 для развертывания.

Мои проблемы исходят из нескольких сайтов, которые мы имеем с чрезвычайно большими библиотеками ресурсов, мы говорим о 20-30 ГБ каждого из PDF-файлов, PowerPoints и видео.

В прошлой настройке эти ресурсы будут в основном жить только на сервере. Разработчик сайта получит новый набор документов, упакует их, отправит их на сервер с помощью FPSE, а затем удалит их локальную рабочую копию, чтобы освободить место.

С TFS Я только что сделал копию текущего состояния сайта, загруженного в решение, и поместил все это в TFS. Результат является громоздким для целого ряда причин:

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

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

Есть ли способ настроить эти каталоги, чтобы они были явно скопированы локально, т.е. когда пользователь открывает решение из TFS, они не копируются, но они доступны, если нам когда-либо понадобится сделать чистую развертывание сайта на совершенно новом сервере? Это в сочетании с правилами пропуска будет решением, но я понятия не имею, если и как это возможно.

Еще один нюанс, это сайт не проекты веб-приложений, которые всегда, кажется, делает вещи только немного более сложные ...

Любые мысли?

Answer 1

Проблема в том, что вы храните несущественные файлы вместе с кодом приложения.

Это огромная проблема, по следующим причинам:

• Автоматизированные строит занять больше времени, так что это сложнее или невозможно создать достойную непрерывную интеграцию.
• развертываний занять больше времени, потому что они должны копировать вокруг гигабайтами несоответствующих файлов
• Разработчики должны иметь дело с загрузкой тонны файлов, которые просто не имеют отношения к ним, чтобы сделать их работу

Перерыв две вещи друг от друга. Храните контент где-то в другом месте. «В другом месте» находится в воздухе, в зависимости от множества факторов.Для начала вы можете просто перенести его в отдельную папку, за пределами папки вашего кода приложения. Разработчики, которые не занимаются контентом, могут скрывать папку. Тем не менее, управление - это действительно плохое место для статического бинарного контента.

Что-то вроде этого:

$/ 
    Dev 
    Application 
     Code 
     Content   
    Main 
    etc 

Разработчики могут отображать $/Dev /, и только маскировать $/Dev/Application/Content. Развертывание становится немного сложнее, если вы это сделаете, потому что у вас есть дополнительный шаг - развертывание кода и развертывание контента становятся отдельными задачами. Идея состоит в том, чтобы просто объединить папки/Code и/Content.

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