内部来源

这有什么不同？

在Impala Studios，我们从拥有共享维护权的两个团队待办事项到通常由模块化和微服务件组成的包含我们所有产品的单个待办事项。 您会看到我们的产品由应用程序，框架，第三方模块和后端服务组成。 每个模块都可以设置为特定产品。 例如，Alarm Clock HD的iOS应用程序内部具有Alarm Clock Framework。 它使用多个SDK和3rd Party模块在应用程序营销和新闻中显示广告，收集数据，并使用我们自己的气象服务来获取新气象。 在我们当前的设置中，整个应用都有一个监护人和一个产品负责人，但是没有一个模块具有特定的所有权。

基本上每个人都拥有内部维护的代码，没有人拥有由外部各方维护的代码。 由于集成产品由其每个模块（不断更新）的最新版本组成，因此创建了相当复杂的依赖关系集。 随着模块的更新，诸如App之类的集成产品将会崩溃。 我们通常也不知道有没有损坏，因为应用程序中的大多数集成都不受自动化测试的影响。 当前，查看已经存在于存储库中一段时间​​的App是否仍然有效的唯一方法是制作和测试当前版本，然后修复发现的内容。

借助Innersourcing，Alarm Clock HD将拥有一个“所有者”（即产品所有者），但是监护权现在将进入每个模块。 现在，团队将负责团队中具有监护人的所有模块。 每个人仍然可以更改这些模块，但是拥有该模块监护权的团队拥有最终批准权。 监护团队确保它使用自己的模块（例如Cocoapods）的依赖处理程序来制作其模块的新版本，然后可用于新版本。

从例子中学习

Google — 20亿行代码

使用内部外包的单个产品的最大示例可能是Google的实现。 Google的所有25,000名工程师都可以在一个存储库中访问几乎所有20亿行代码！ 我们可以从Google中学到的东西：

• 他们将代码保存在团队拥有的“目录”中。
• 除目录外，任何开发人员都可以进行任何更改，您的更改必须经过所有者的批准。
• 分支-它们具有“基于主干”或“发布分支”的模型。 尽可能晚地制作master分支的快照，并在此基础上开发新功能。 如果主服务器上已更新了开发所需的内容，则可以将其“放入樱桃”到发行分支中（由于其大小，他们甚至没有选择与主分支保持同步）。 发布分支是生产的基础。 我们可以考虑使用GitLab Flow，当然也可以考虑使用CocoaPods冻结版本。
• 它们具有每次提交时运行的单元测试的代码覆盖率。
• 他们使用拉取请求和自动部署进行代码检查。

贝宝（Paypal）-开源和内部源之间的优势

有许多公司一直活跃在开源社区中，而不是从专有或内部源码，甚至是开源方面发生变化的公司。 Google和Facebook在开放源代码许可下拥有部分代码，Apache基金会和Ubuntu / Canonical拥有完全基于社区的软件。

Paypal是后来者，但自2014年初以来，他们在kraken.js项目上开始从Java过渡到JavaScript和Node.js时，就采用了Inner Source。 他们注意到，要为许多项目做出贡献，就必须采用一种新的工作方式。 一个重要的变化是迁移到GitHub和使用Git。 另一个是就质量标准达成共识，例如单元测试。 最后，他们注意到开放源代码贡献者的工作是分散的，而他们正在迁移到同一地点的团队。 面对面交流的缺点是，对于不了解该软件的人而言，没有文档记录，他们必须学习使用readme.txt，changelog.txt并在git中进行文明的在线公开讨论注释。 由于kraken.js是开源的，因此与外部贡献者的通信在某种程度上迫使了这一点。

O’Reilly上提供了对Paypal内源的深入了解。

我们可以学到的东西：

• 使用Bitbucket进行文档记录，自述文件，变更日志和问题跟踪。
• 促进质量标准和在共享代码上引入单元测试的工作方式。
• 关于变更的文明，开放的沟通。
• 尽可能开源，并与社区互动。

从内源之路开始。

如果要在Impala Studios进行内部源代码处理，则可能需要首先处理以下几件事：

• 更改监护权以覆盖所有共享模块：应用程序，框架，第三方库和服务。
• 发布并显示哪些团队是哪些模块的可信任提交者。
• 逐步使模块模块化，可构建和可测试。
• 在存储库中逐步制作文档。

一旦到位，我们可以：

• 开始为我们使用的开源模块做出贡献。
• 开源一些我们的专有软件。