我正在为在不同服务器上运行的第三方应用程序开发和维护一堆perl glue代码。每个服务器当前都有一个git repo，用于开发在那里运行的代码，以及一个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提取到他们自己的repo中进行源代码控制，但是希望所有脚本最终都在测试和生产环境中的相同文件夹结构中。
我目前实现这一目标的想法包括为共享代码创建一个repo，并将其设置为本地存储库的远程仓库。
共享回购：
sharedscript1.pl
perl-modules/sharedmodule1.pm
然后我可以将共享仓库定义为本地仓库的远程仓库，并将提交从那里拉入本地代码。在测试并提交后，我可以使用现有的部署过程将所有内容推送到生产环境。
这是一个合理的设置吗？我应该注意这种方法的任何问题/陷阱？有没有更好的方法来处理这种情况？
注意：我希望保持相当轻量级，最终的构建将是三个或四个本地服务器，可能有十几个脚本和几个本地模块。共享仓库目前有两个脚本和一个模块，可能还有一些。
附加说明：我正在运行git版本1.6.0.2
答案 0 :(得分：2)
Having all files be in the same folder may cause yourself or somebody else difficulty when trying to determine what source each file came from, and accordingly how it should be maintained.
If your dependencies are not reflected somehow in your file structure, then do not be surprised when you or someone else starts adding in localized code and committing to your 'core' repository.
You can still have all files be effectively in the same location, however, by using softlinks to the localized directories.
For example, the following softlink structure would give you flat file structure for usage, but hierarchical file structure for dependencies and modular maintenance.
basedir/perl-modules/localmodule1.pm -> ../../localized-code/server1/perlmodules/localmodule1
basedir/localscript1.pl -> ../localized-code/server1/scripts/localscript1.pl
Using a simple install script, you could just generate all softlinks to the relevant server1 folder or subfolder when you are installing on a server needing the server1 code.
To maintain version control, you can gitignore all files except the core modules in the base directories, and use git submodules to maintain code for each of the localized directories.
That way, you dont need to have all submodules included in all servers.
As a more general potential pitfall, be wary of complicated installation or upgrade processes. Eventually, you are going to install the system on multiple servers. As a potential guidepost for yourself, remember that as per the JOEL test, if you cannot make a build in one step, then your install process is error prone. Test your install process and you will find your own potential issues. If you can run a clean install for all your servers, and still be in a position to do maintenance, then you should be fine!