Как отделить локальный от общего кода с помощью git repos

Question

Я разрабатываю и поддерживаю кучу кода клея perl для сторонних приложений, работающих на разных серверах. На каждом из серверов в настоящее время имеется репозиторий git для разработки кода, работающего там, и механизм push-to-deploy для смены изменений на соответствующие производственные серверы.

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

Текущая структура хранилища:

Сервер 1 ~/USR/Dev:

localscript1.pl 
sharedscript1.pl 
perl-modules/localmodule1.pm 
perl-modules/sharedmodule1.pm 

Сервер 2:

localscript2.pl 
sharedscript1.pl 
perl-modules/localmodule2.pm 
perl-modules/sharedmodule1.pm 

Я хочу, чтобы вытащить sharedscript1.pl и sharedmodule1.pm в их собственное репо для управления версиями, но предпочли бы, чтобы все сценарии попадали в одну и ту же структуру папок в тестовых и производственных средах.

Моя нынешняя идея для реализации этого предполагает создание репо для общего кода и установку этого в качестве удаленного репо для локальных репозиториев.

Shared репо:

sharedscript1.pl 
perl-modules/sharedmodule1.pm 

я мог бы определить общий репозиторий в качестве удаленного для локальных операций РЕПО и тянуть коммиты оттуда в местный код. После тестирования и фиксации я могу использовать мой существующий процесс развертывания, чтобы подтолкнуть все к производству.

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

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

Дополнительное примечание: Я бегу Git версии 1.6.0.2

Answer 1

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

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

Вы все равно можете иметь все файлы в одном и том же месте, однако, используя программные ссылки в локализованных каталогах.

Например, следующая структура софтлинк даст вам плоскую структуру файлов для использования, но иерархическую структуру файлов для зависимостей и модульного обслуживания.

basedir/perl-modules/localmodule1.pm -> ../../localized-code/server1/perlmodules/localmodule1 
basedir/localscript1.pl -> ../localized-code/server1/scripts/localscript1.pl 

Используя простой сценарий установки, вы можете просто создать все softlinks к соответствующей папке или вложенным при установке на сервере нуждающегося в код.

Для поддержания контроля версий вы можете gitignore всех файлов, кроме основных модулей в базовых каталогах, и использовать git submodules для поддержки кода для каждого из локализованных каталогов.

Таким образом, вам не нужно иметь все подмодули, входящие в состав всех серверов.

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