什么是“内源”开发，您应该使用它吗？

Inner Source，通常称为 InnerSource，是指在组织内采用开源流程和开发方法。“开源”意味着创建公开可用的工具，而内部源意味着您正在使用开放派生的方法进行内部项目。

开源工作流有助于轻松协作和快速迭代。GitHub 等平台上可公开访问的问题和合并请求让任何人都可以为项目做出贡献。在促进维护者和用户之间定期讨论的环境中，错误被快速、安全和透明地发现和修补。

该模型与大型组织内部的软件开发方式形成鲜明对比。在这些环境中，工具是由各个团队以临时方式开发的。人们各自为政，为各自的领域做出贡献，而忽略了其他地方正在进行的重叠工作。

内源介绍

该内源移动应用从开源开发学会了组织内部项目的经验教训。它提倡让所有人都能看到所有代码，创造一种更加开放的文化，让团队可以找到可能对他们的工作也有用的现有项目，然后贡献自己的改进。

在许多组织中，新的源代码存储库将仅限于需要处理它们的个人。采用内部源模型意味着默认情况下使所有内容都可见。这鼓励团队成员探索组织的整个代码语料库并为讨论提供输入，即使项目并不严格属于他们的主题领域。

内部源代码也不仅仅是关于代码。它可以扩展为包括与业务、其运营和其软件相关的更广泛的资产和文档。目标是让个人能够自主选择任务，并在他们认为对组织有益的地方贡献他们的经验，即使他们被雇用到特定的重点领域。

内在的好处

“内部源”架构的支持者注意到该方法的几个显着优势，包括减少浪费、加快启动时间、减少团队之间的紧张局势以及提高代码质量。这些结合起来可以提高组织的生产力和工作场所文化。

减少浪费，增强重用——大型组织最终可能会在不同团队拥有的多个项目中复制类似的代码。如果团队没有相互交谈，那么您现在拥有三个类似的缓存库的事实可能会被忽视。在内部发布所有代码将提醒其他人注意常用工具的存在，然后鼓励在单个代码库上共享迭代。轮子不再被重新发明，让每个人都专注于任务并加快发布时间。

改进的代码质量——公开编写的代码更容易暴露，因此错误可能会在开发过程的早期出现。如果新团队采用共享库，则可能会发现以前未被注意到的问题。实施修复将使所有使用该库的项目受益。

减少团队之间的紧张——虽然最初转向开放模型可能看起来不舒服，但内部源开发旨在打破障碍并加强协作。当您发现相邻团队构建了您一直在使用的库的更好版本时，封闭式开发可能会产生不安的情况。在开放模型中，这可以通过在包含整个团队所需功能的共享代码库上一起迭代来解决。

内部源使组织结构扁平化，让所有开发人员对正在进行的工作有相同的看法。接受来自“拥有”项目的团队外部的贡献，可以获得新鲜的眼光和扩展的解决方案库。

实现内部源工作流

最简单的内部源代码是通过转到您的版本控制平台并将项目的可见性从私有更改为内部来实现的。在实践中，如果您要成功地将内部源模型引入现有团队环境，您将需要一个比这更深思熟虑的计划。

任何转型都有两个基本方面：沟通和工具。前者是指教育团队成员了解正在发生的事情以及他们将如何为已打开的项目做出贡献。“设置和遗忘”访问级别将无效，因为人们将不知道他们的新能力以及何时可以使用。

第二个方面，工具，涉及选择适当的软件实用程序来管理开放的工作流程。一个正常运作的软件团队可能已经在使用某种形式的版本控制，例如GitOps来管理他们的代码。但是，在整个组织中，精确的使用模式可能会有很大差异。

内部源调用统一的开发模型，该模型将在所有项目中一致地工作。这意味着充分利用 Git 和您的托管平台（例如 GitHub 或 GitLab）的功能。

贡献者应该能够在拉取请求中提交更改，然后维护人员进行审查和合并。拉取请求应该由在 CI 管道中运行的通过测试套件补充。这让维护团队相信更改是有效的，并确保所有代码都符合相同的标准。通过自动化测试和检查使代码库自我验证有助于消除体验中的摩擦。

您还应该考虑如何存储和公开诸如文档和问题列表之类的支持资产。为 API 文档和架构参考创建一个开放的团队 wiki；确保在一个中心位置跟踪所有错误和功能请求。这将使整个组织的人们都能找到他们需要的信息。它还使个人能够在更安静的时期为任意项目提供增强功能——任何人都可以找到错误报告并开始解决它们，从而改进所有下游存储库。

要考虑的缺点

内部源已经在许多组织中成为现实。在需要提高效率和吞吐量的情况下，潜在的好处是诱人的。与任何工作方法一样，它不一定适合所有环境。

内源最常见的担忧之一是其对安全和信息披露的影响。内部源代码和更广泛的开源生态系统之间的相似之处仅止于此：开放库或框架中的代码不包含任何敏感性，而您可能在工作中处理受严密保护的专有系统。

有些项目总是需要锁定，只有利益相关者和直接负责的实施团队可以访问，这是很自然的。但是，拥有一些具有敏感源的高风险项目，在这些项目中让它们在整个组织中可见是不安全的，不应意味着内部源计划的结束。

开放可以安全暴露的项目还是值得的。您还可以将私有项目的非敏感部分抽象为可公开访问的新共享库。这使内部资源的好处更接近您的敏感资产，而无需实际透露它们。

另一个内部源挑战是将期望传达给开发人员。开发人员可能对探索开放项目持谨慎态度，尤其是在将内部源引入历史上封闭的组织时。这可以通过多种方式解决，例如分配时间让开发人员检查其他团队编写的代码。

从小规模开始，只公开对组织中的许多不同团队有用的核心库也很有帮助。一个好的选择可以是一个众所周知但私有的组件，它以不可靠或过时而闻名——想想“再次报告 ApiClient 的错误”。开放该组件使开发人员能够根据需要贡献自己的修复程序，从而提高生产力并促进内部源头心态的有机增长。

如果您确实尝试了这种技术，请先小心地警告原始项目作者——即使它可以全面提高效率，但有些人可能会将其他人对以前“他们的”代码的贡献视为一种侮辱。传达为什么将内部资源引入组织，以及打开单个项目的具体原因。

结论

内部源是指从开源社区中获取开发方法并将其应用于内部项目和流程。它促进了对有用代码和文档的无阻碍访问，同时促进了协作和交流。

如果实施得当，内部资源可以成为组织的一个差异化点，可以减少冗余、增加吞吐量并培养更公平的开发文化。选择默认打开项目可以让原始作者利用整个组织的人才。与领先的开源框架和库收集社区的集体能力一样，内部源代码也可以创建超越任何单个团队可以实现的内部工具。

内部来源可能很难正确。它可能会导致代码所有者的反对和开发人员的警惕。在引入任何形式的内部源开发时，通过清楚地记录期望和工作程序，使人们保持一致。每个人都需要在为内在源泉的全部好处做出贡献时感到自在。