第 18 章 组织基础设施 组织基础设施代码
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
基础架构代码库可能包含各种类型的代码,包括堆栈定义、服务器配置、模块、库、测试、配置和实用程序。
如何在项目间和项目内组织这些代码?如何在不同版本库之间组织项目?基础架构代码和应用代码是放在一起,还是应该分开?如何组织具有多个部分的房地产代码?
组织项目和资料库
在这种情况下,项目是用于构建系统离散组件的代码集合。对于单个项目或其组件可以包含多少内容,并没有硬性规定。例如,"构建堆栈的模式和反模式 "中就描述了基础设施堆栈的不同范围级别。
一个项目可能依赖于代码库中的其他项目。理想的情况是,这些依赖关系和项目之间的界限定义明确,并清楚地反映在项目代码的组织方式中。
康威定律(见"根据组织结构调整边界")指出,组织结构与组织所建立的系统之间存在直接关系。团队结构和系统所有权以及定义这些系统的代码之间的不协调会造成摩擦和低效。
在项目之间划定边界的另一面是,当项目之间存在依赖关系时,对项目进行整合,第 17 章对堆栈进行了描述。
请参阅"集成项目",了解不同依赖项与项目集成的方式和时间。
如何组织代码的问题有两个方面。其一是如何放置不同类型的代码--堆栈、服务器配置、服务器映像、配置、测试、交付工具和应用程序的代码。另一个问题是如何在源代码库中安排项目。最后一个问题比较简单,我们就从这里入手。
一个存储库,还是多个存储库?
如果您有多个代码项目,应该把它们都放在源代码控制系统的一个库中,还是分散到多个库中?如果使用一个以上的版本库,是每个项目都有自己的版本库,还是将一些项目归入共享版本库?如果将多个项目安排在不同的版本库中,应该如何决定哪些项目应该分组,哪些项目应该分开?
需要考虑一些权衡因素:
-
将项目分成不同的版本库,可以更容易地在代码层面保持界限。
-
让多个团队在单个版本库中处理代码会增加开销并产生冲突。
-
将代码分散到多个版本库中会使处理跨版本库的变更变得复杂。
-
保存在同一版本库中的代码是版本化的,可以一起分支,这简化了一些项目集成和交付策略。
-
不同的源代码管理系统(如 Git、Perforce 和 Mercurial)具有不同的性能和可扩展性特点和功能,以支持复杂的场景。
让我们根据这些因素来看看跨版本库组织项目的主要选项。
一个存储库搞定一切
一些团队,甚至是一些较大的组织,会将其所有代码维护在一个单一的仓库中。这就要求源码控制系统软件能够根据使用水平进行扩展。随着代码库的规模、历史、用户数量和活动水平的增长,有些软件在处理代码库方面会遇到困难。1因此,拆分版本库就成了一个性能管理问题。
单一版本库更易于使用。人们可以签出他们需要处理的所有项目,确保他们拥有所有项目的一致版本。有些版本控制软件提供稀疏签出(sparse-checkout)等功能,允许用户使用版本库的子集。
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access