问题描述
目前有一个包含自动化代码、基础设施代码和Lambda代码的Git仓库。自动化代码主要使用Fabric、Python和unittests；基础设施代码主要使用CloudFormation、Docker-compose和一些Terraform；Lambda代码主要是Serverless代码和一些Fabric；还有一些使用Dockerfile从该Git仓库构建Docker镜像的代码。用户考虑将Git仓库分离，并使用Git子模块，因为这样看起来更加清晰。用户想知道在这个过程中是否有什么提示或建议。
用户担心大多数关于单一仓库和多个仓库的提示主要是针对构建微服务的程序员，而不是针对DevOps / SysAdmins的。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
发现性
- 开发人员和运维人员发现某个功能的代码有多容易。是否有明确的指导方针来确定代码放在哪里？是否通过自动化方式强制执行？新的仓库是否自动链接为正确位置的子模块？构建或部署过程是否依赖于树结构，以确保人们需要将其放在那里才能被注意到？仓库的大小如何？在特定位置搜索代码需要多长时间？是否有通用的
lib/目录，开发人员和运维人员最终共享创建新的意外隐式依赖项的库？
可部署性
- 是否需要在部署的机器上存在任何代码？你是否希望通过同步仓库进行此类部署，还是有其他已建立的部署机制？在第一种情况下，是否会在部署过程中添加不需要的其他代码？
可持续性
- 你正在使用的概念是否经得起时间的考验？你是一个单一产品的公司，但也许在你的未来会有新的产品？添加新产品会如何影响代码？新产品是否会有新的单一仓库？对于产品之间的共享代码怎么办？查看公司的路线图，无论是6个月、2年还是5年后，你所做的任何事情都会如何？这样的选择在实践中往往很难改变（尽管理论上不应该改变）。
DevOps
- 你真的希望消除开发人员和运维人员之间的障碍。因此，即使只是为运维人员单独创建一个单一仓库，也可能会创建这样的障碍。代码的操作和部署、环境的搭建、服务的设置，所有这些都应该在开发人员的掌握范围之内，并明确期望与运维团队协调开发这样的代码，而不是依赖于其他人为他们做这些事情。如果一切顺利，你的开发人员会在产品已经投入生产几个月后继续提交代码，并在部署的所有方面都有所作为。提交包含产品和部署更改的提交有多容易？这些提交如何分组？运维人员对产品运行时代码的可见性如何？开发人员对产品管理代码的可见性如何？
方案1：使用Git子模块
- 首先，确保你已经安装了Git，并且对Git的基本操作有一定的了解。
- 在你的主仓库中，使用以下命令将子仓库添加为子模块：
git submodule add <子仓库URL> <子模块路径>
例如：
git submodule add https://github.com/user/repo.git submodules/repo
这将在主仓库中创建一个名为submodules/repo的子模块，并将子仓库的内容克隆到该路径下。 - 提交并推送你的更改：
git commit -m "Add submodule"
git push - 其他开发人员可以通过以下命令克隆主仓库，并初始化子模块：
git clone <主仓库URL>
cd <主仓库目录>
git submodule init
git submodule update
这将克隆主仓库，并将子模块的内容初始化和更新到本地。 - 现在，你可以在主仓库和子仓库之间进行开发和管理，每个仓库都可以独立进行提交和推送。
方案2：保持单一仓库
如果你担心多个仓库会引入不必要的风险，可以考虑保持单一仓库。这样可以避免访问控制、可用性或计费问题导致的仓库不可用。
此外，单一仓库也符合”DevOps”的理念，即软件开发人员和系统管理员应该共同合作，了解彼此的领域，而不是传统的”过墙责任”。如果开发和运维应该共同工作，为什么运维和运维要分开呢？
方案3：根据逻辑分割仓库
如果你倾向于更多的仓库或子模块，你可以根据逻辑将仓库分割。例如，你可以将自动化代码和基础设施代码放在同一个仓库中，将测试用例用于验证基础设施的有效性。对于Lambda函数，你可以考虑它们是否可以用于其他类型的基础设施，是否可以扩展为其他功能。
此外，你还可以考虑如果有新人加入团队，他们是否能够理解你的仓库并提交拉取请求？或者他们会感到不知所措？较少复杂的仓库可以使其他用户在较短的时间内做出有意义的贡献。
总结
在将DevOps Git仓库分离为多个仓库时，你可以选择使用Git子模块，保持单一仓库或根据逻辑分割仓库。每种方案都有其优缺点，你可以根据自己的需求和团队的工作流程选择适合的方案。