12Factor 应用程序代码库因素我应该拆分答案

【问题标题】：12Factor app codebase factor should I split12Factor 应用程序代码库因素我应该拆分
【发布时间】：2013-04-28 21:35:46
【问题描述】：

我最近被 12Factor 应用程序所吸引，因为它是我应该强迫自己遵循的强有力的指导方针。所以在我目前正在进行的一个项目中，我决定使用它们。虽然我对我的代码结构有疑问：

我有一个可以创造新工作的网站，人们可以在那里查阅工作的结果。作业被排入分布式队列（ftm Redis），工作人员接受每个作业并执行它们。我决定将代码库拆分为 2：

中间有一个节点包，封装了通信（排队等），节点之间唯一的通信是通过Redis。

所以我只是想确保在我构建分布式系统时这仍然与 12factor 保持一致。如果不是，我应该在一个代码库中构建所有内容，并使用一个启动脚本来启动一个或另一个？

感谢您的帮助

【问题讨论】：

【解决方案1】：

保持简单，但没有更简单的意义。如果将所有内容保存在一个代码库中对您来说更简单，那就从这种方式开始。开发是一个迭代过程，假设您做错了，并准备好在事情开始变得笨拙时进行更改。

过早地优化（或抽象）您的代码（或工作流程）总是不明智的。

【讨论】：

这是真的。但是，在单个代码库中制作它会使其依赖于实际上并不存在的依赖项（例如，我正在考虑 express）。但确实，一个代码库将使包括部署在内的事情变得更容易。
我想我会从一个开始，当你发现你可以将它们作为一个应用程序系统来维护时，而不是一个应用程序将它分开。我们经常在 heroku 这样做。我们将开始编写一些东西，然后注意到应用程序的组件之间存在不必要的耦合，并在我们重构它们时将它们拆分为一个应用程序系统。

【解决方案2】：

我决定将代码库拆分为 2

嗯，12 因素网站上的第一项说“在修订控制中跟踪一个代码库，许多部署”

从您的描述中，我认为无法判断您遵循指南的程度。

【讨论】：

如果两者都可以用作独立的软件并且可以这样维护，那么将它们分开可能是有意义的。
是的，让我犹豫的是：“如果有多个代码库，它就不是一个应用程序——它是一个分布式系统。分布式系统中的每个组件都是一个应用程序，每个组件都可以单独遵守十二-因素。”
是的，这是一种权衡，没有正确的答案。列出您接下来可能添加的功能。有多少需要同时接触两个代码库？如果是他们中的大多数，那么考虑将他们重新加入 1 个 repo。