Я хочу отделить двоичные файлы (носители) от моих репозиториев кода. Стоит ли оно того? Если да, то как я могу ими управлять?

Наши репозитории становятся огромными, потому что у нас есть тонны медиафайлов (сотни файлов JPEG размером 1 МБ, сотни PDF-файлов и т. д.).

Из-за этого нашим разработчикам, которые проверяют эти репозитории, приходится ждать ненормально долго для определенных репозиториев.

У кого-нибудь еще была эта дилемма раньше? Правильно ли я поступаю, отделяя код от медиа? Вот некоторые проблемы/беспокойства, которые у меня были:

  • Если я перенесу их на медиа-сервер, я боюсь, что разработчику будет сложно их использовать. Вместо обновления одного сервера ему/ей теперь придется обновлять два сервера, если они выполняют как программную логику, так и обновления мультимедиа.
  • Если я перенесу их на медиа-сервер, мне все равно придется контролировать версии медиа, не так ли? Таким образом, разработчику придется фиксировать обновления кода и фиксировать обновления мультимедиа.
  • Как разработчик будет тестировать локально? Я мог бы заставить свой сайт использовать абсолютные URL-адреса, например src="http://media.domain.com/site/blah/image.gif", но это не сработает локально. Я предполагаю, что мне придется изменить шаблон моего сайта, чтобы решить, является ли он локальным/разрабатываемым или производственным, и на основе этого изменить BASE_URL.
  • Стоит ли все это делать? Мы имеем дело примерно со 100-150 сайтами, а не с дюжиной крупных сайтов, поэтому у нас около 100-150 репозиториев. У нас не будет ни времени, ни ресурсов для изменения существующих сайтов, и мы можем реализовать это только на совершенно новых сайтах.
  • Мне все равно придется хранить скрипты, генерирующие медиафайлы (генераторы pdf), и сгенерированные медиафайлы в репозитории кода, верно? Было бы очень сложно обновить все эти генераторы PDF-файлов до POST-файлов на внешние медиа-серверы, а также с учетом кэширования.

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


person meder omuraliev    schedule 21.10.2010    source источник
comment
Возможно, вы захотите сообщить нам, какую систему контроля версий вы используете. (Мне очень любопытно, какая современная система контроля версий будет работать медленно из-за большого количества больших файлов в ее репозитории.)   -  person sbi    schedule 21.10.2010
comment
Ах, ты меня понял. Мы на самом деле (да, да, да 1980) все еще используем CVS. У нас еще не было ни времени, ни ресурсов для перехода на git.   -  person meder omuraliev    schedule 21.10.2010
comment
Хорошо, что вы спрашиваете об этом сейчас, прежде чем погрузиться в переход к инструменту. Как часто, если вообще когда-либо, эти бинарные активы меняются? Их шаблоны модификации повлияют на стратегию, которую вы хотите использовать.   -  person Phil Miller    schedule 22.10.2010
comment
@Novelocrat — обновления изображений ежедневно обновляются на десятках сайтов.   -  person meder omuraliev    schedule 22.10.2010
comment
Итак, история в чем-то вроде Git станет огромной, даже если у каждого сайта будет свой собственный репозиторий. Следующий вопрос: насколько тесно связаны код и носитель? В частности, соответствуют ли изменения мультимедийного контента непосредственно изменениям кода?   -  person Phil Miller    schedule 22.10.2010
comment
Часто, когда перед разработчиками ставится задача, им одновременно даются как программные, так и мультимедийные изменения. Таким образом, изменения во внешнем интерфейсе + изменения в программировании + медиа-контент обычно обновляются в одной и той же задаче. Очень обычная повседневная вещь.   -  person meder omuraliev    schedule 22.10.2010
comment
Обратите внимание, что SVN также хранит двоичные файлы как различия, в то время как CVS должен хранить их подробно, версия за версией, потому что у него нет алгоритма сравнения двоичных файлов. CVS взорвет дисковое пространство вашего репозитория, если вы зарегистрируете много бинарных файлов.   -  person sbi    schedule 23.10.2010


Ответы (1)


Во-первых, да, отделение мультимедиа и сгенерированного контента (например, сгенерированного PDF-файла) от системы управления версиями — хорошая идея.
Это связано с:

  • дисковое пространство и время оформления заказа (как вы описываете в своем вопросе)
  • отсутствие функции CVS, фактически используемой файлом такого типа (без различий, без слияния, только метка и ветки)

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

Двоичные файлы обычно делятся на две категории:

  • несгенерированные двоичные файлы:
    их лучше хранить в репозитории артефактов (например, Nexus), под меткой, которая соответствует метке, используемой для текстовых источников в системе контроля версий.
  • сгенерированные двоичные файлы (например, ваш pdf):
    в идеале они не должны храниться в каком-либо репозитории, а должны создаваться только на этапе управления выпуском для последующего развертывания.
person VonC    schedule 22.10.2010