PouchContainer 开源版本及内部版本一致性实践
为什么要做内外版本一致
对外开源是提升影响力、共建生态的有力手段。在项目对外开源的过程中，首先是将可以开源的部分抽离出来，发布一个“开源版本”，与内部基础设施相关的部分则留在内部版本中。在后续的开发中，开源版本随着社区不断演进，内部版本则随着内部的需求不断迭代。如果没有明确定义内外部版本的边界、代码同步不完全、不及时，将会导致内外版本越走越远，变成两个不相干的项目。
促使我们开始做内外版本一致事情的，主要是以下三点考虑：
- __降低维护成本: __这也是同步工作的出发点。减少多版本维护的工作负担，也方便团队的交流。
- __发挥社区的优势: __吸收社区力量是开源的一个重要考虑，让社区的力量真正在内部发挥价值。社区会有一些我们没有考虑到的需求，有集结社区力量的更严格的 review，与 github 集成的强约束 CI 等。
- __降低功能同步的风险: __在内外部版本不同源的情况下，将外部代码合并进来非常容易冲突。代码模块较多，解决冲突的过程中，一不小心就会引入非预期的修改，而这在合并的过程中，很难发现。
本文将详细说明 PouchContainer 是如何做到内外部版本一致的。
差异梳理及边界定义
PouchContainer 开源已经将近一年了，在内外部版本差异梳理之前，没有人能讲清楚两个版本之间的差异。于是我用 Beyond Compare4 等软件，进行文件级别的比对，一个个找出内外部不同的代码，进而梳理出内外部功能级别的差异。所幸内外部的差异比我想象中的要小。主要有以下几类差异：
- 对内部老系统的接口兼容
- 为内部系统开的后门接口
- 对接内部基础设施的逻辑，如存储，网络
- bugfix, feature 没有互相同步
前三类差异是集团内针对 PouchContainer 的定制化内容。当然，有一些是目前迫不得已加上的临时逻辑。在后续的发展中，将会改造、下线。第四类的差异，主要原因在于开发者没有版本同步的意识：bugfix 在内部紧急修复之后，没有同步到社区。社区开发者的 bugfix, feature 没有及时同步进内部代码。
在差异梳理出来之后，需要明确内外部的功能边界。能开源的就开源，独有的功能继续保留。抹平非功能性的不一致。
一致性改造
__版本同步的根本还是提升软件的可拓展性__，允许共用一套核心代码，针对不同的业务场景进行定制。所以我们面对的问题不仅是内外部版本的一致问题，应该是三版本、四版本、多版本的一致问题。这也是 PouchContainer 赋能其他业务场景的基础。同样也是开源项目内部使用的必修课 所以，我们做的第二步是通过__插件机制__提升 PouchContainer 的可拓展性。目前我们支持 API, container, daemon, volume，cri 这五种插件。具体见文档。
插件的设计旨在提升软件的扩展性，但不允许插件改变原有的工作流程。PouchContainer 提供了对 container, daemon, volume, cri 关键步骤的 hook。以 daemon 插件为例，该插件提供了对启停接口的 hook。插件实现者可以在 daemon 启动前运行一些其他程序，比如 dfget。在 daemon 停止前，做一些清理操作。
// DaemonPlugin defines places where a plugin will be triggered in pouchd lifecycle
type DaemonPlugin interface {
// PreStartHook is invoked by pouch daemon before real start, in this hook user could start dfget proxy or other
// standalone process plugins
PreStartHook() error
// PreStopHook is invoked by pouch daemon before daemon process exit, not a promise if daemon is killed, in this
// hook user could stop the process or plugin started by PreStartHook
PreStopHook() error
}而 API 插件通过将路由表传给插件，允许插件实现者扩展、删除、修改 API。这让接口有了很大的灵活性。
import "github.com/alibaba/pouch/apis/server/types"
// APIPlugin provide the ability to extend PouchContainer HTTP API and change how handler behave.
type APIPlugin interface {
// The default handler of each API would be passed in while starting HTTP server.
// UpdateHandler could register extra HTTP API to PouchContainer server,
// change the behavior of the default handler.
UpdateHandler([]*types.HandlerSpec) []*types.HandlerSpec
}通过插件化的改造，绝大部分的内部 PouchContainer 定制化逻辑都在插件中实现了。插件单独一个文件目录，在代码合入的时候几乎不会产生冲突。之后将内部插件逻辑和其他差异一个个 commit 到开源分支上。__做到内外部版本的同源。__
稳定性保障
PouchContainer 开源版本代表通用功能，如果外部开发者在通用版本上迭代的新增功能，集团内部用不到，该如何保障外部功能同步到内部之后，不影响内部的现有功能的？
首先内部版本是有一套完整的测试覆盖的，__内部测试在开源测试的基础上还包含针对内部场景的测试__。内部测试通过，我们便认为该版本是符合内部场景要求的，开源版本没有影响内部稳定性的。如果测试不通过，有两个选择，一是重新评估开源通用功能，是否有代码缺陷；二是在内部仓库打补丁。以此来保障开源代码同步至内部后的稳定性。
建立新的秩序
我们先来看看，在这之前的工作流是怎样的。开发者分别在内部仓库和开源仓库提代码，紧急一些的需求会先在内部仓库提 merge request，不那么重要的需求会先在社区提 PR。有人会定期将开源分支 merge 进内部仓库。这里有几个问题，一是内部也有一套测试流程，这套流程可能不像 travisCI 或 circleCI 对接 github 那么方便，有些设计好的测试在内部仓库甚至不会跑。二是没有插件化前，某些功能在内外部有两种不同的实现，这在每次手动 merge 代码的时候几乎都会冲突，解决冲突的过程很容易引入非预期的修改，下次又继续冲突。
在完成一致性改造之后，我们建立一套规则来保证后续不会再出现版本分离的事情。
- 原则上非私有增强，应该先在社区提交 PR，merge 之后通过同步机制进入内部版本
- 如果时间紧急，bugfix 先在内部版本上提交。后续 commiter 负责将其 cherry-pick 到社区。社区 review 发现需要继续修改的，将修改另提一个 commit，这样保证 commit 不与内部仓库冲突
- 代码同步，由机器人定时提交 merge request 将开源同步至内部
在 merge 的时候，保证是 fast-forward 的，这样内外部的 commit 是一一对应的，减少冲突。
总结
开源，能帮助项目吸收外部养分，加速项目的演进。在一致性的改造过程中，帮助开发者明确内外部版本的边界，打造同一份核心代码，提升核心代码的可定制化能力，更好地服务于不同的场景。
