最近，TiDB 终于公布了一个里程碑的版本 – TiDB 5.0。这里，我并不打算过多的聊 TiDB 5.0 架构实现、技术细节，这个大家能够参考 What’s New in TiDB 5.0 以及后续的技术文章，我想聊聊其余的货色，也就是咱们是通过什么样的形式来打造 TiDB 5.0 的。
首先，咱们首先须要抵赖一个事实，就是开发一款数据库是十分艰难的一件事件，我甚至都认为它是世界级别的挑战。在 PingCAP，咱们遇到的难度可能比其余数据库厂商更大，包含但不限于：
- 如何协调寰球数百人的研发团队来开发 TiDB？
- 如何协调社区数百人的贡献者给 TiDB 提交代码？
- 如何保障 TiDB 在云上，云下都能稳固运行，基于物理机，VM，K8s 等也能稳固运行？
- 如何让 TiDB 能跟不同数据处理生态（譬如 Flink，Kafka 等）无效集成？
- 如何让 TiDB 满足寰球不同行业，不同的场景？
- 如何在反对公司商业化工作的同时，保留足够的带宽去研发 5.0？
- 等等。。。。。。
能够看到，咱们有太多的问题要解决，那么咱们是如何来解决这些挑战的呢？当然，咱们一开始也是没法解决所有的问题的，当初咱们依然面临微小的挑战，但得力于咱们一直迭代并且积淀下来的一整套工程体系，咱们开始缓缓变得熟能生巧。这里，我会简略的介绍一下咱们到底是怎么做的，当然，看到最初，大家可能会发现，原来我说的货色其实十分的简略，但确确实实会十分的高效。
PMC 和 TiDB TOC
我始终认为，在 PingCAP 做研发是一件难度挑战十分大的事件，因为研发同学会面对里面各种的需要，尽管咱们有产品经理，但要均衡好各个业务线的诉求，也是一件很艰难的事件。
所以咱们在 PingCAP 外部成立了一个产品治理委员会的组织，简称 PMC（Product Management Committee），PMC 外面有产研的同学，也有各个业务线的负责人，大家定期坐在一起散会，用来确定需要的优先级，以及对下一个版本要带上的性能达成统一。尽管这并不是一个最优的解法，但至多能让产研跟业务团队能疾速的对齐，不会呈现一个版本公布的时候，业务方说『怎么这个需要没做』这样的事件。
PMC 只是 PingCAP 外部用来协调各个部门对产品达成共识的组织，PingCAP 也是 TiDB 这个社区的一份子。所以咱们也跟社区的同学一起成立了 TiDB Community TOC(Technical Oversight Committee)。TOC 作为 TiDB 社区技术层面的最高决策机构，在 TOC 外面，会有来自各个 TiDB 社区我的项目的外围维护者，和来自 PingCAP 的代表，来自其余社区外围奉献企业的代表，定期会交换 TiDB 我的项目的停顿，以及一起探讨一些大的性能是否会进入 TiDB，或者决定一些我的项目是否能在 TiDB 社区孵化。对于社区单干，如果有机会，咱们前面会写一篇更具体的文章来介绍咱们是如何打造 TiDB 社区的。
火车发版模型
之前，TiDB 采纳的比拟传统的一年或者半年发一个大版本的传统，但如果一个版本外面要带的性能太多，而后就呈现了软件工程畛域最相熟的事件 – 延期 。所以前面咱们引入了火车发版模型。
火车发版模型其实就是一种麻利迭代模型，咱们会每隔 2 个月定期公布一个版本，咱们会关注发版的节奏和版本的品质，如果一个性能在这个版本外面没有做完，咱们依然会公布这个版本，但会让这个性能顺延到下一个版本外面。这个对于业务方也有一个预期，他们会明确的晓得，他们要的某个性能如果曾经布局进入到某个版本了，最迟就是等 4 个月，所以业务方会依据这个来管制客户的预期。
有了火车发版模型，大家的工作就齐全能迭代开展了，整个迭代流程相似如下：
- 每次版本要完结的时候，产品经理就会开始跟业务，研发一起探讨下一个版本要带上的性能，以及评估进去优先级，还有性能须要多少人月来开发。
- 产品经理会将所有的输出整顿成一个列表，咱们外部叫做装箱单，让 PMC 决策，PMC 会一起探讨哪些性能应该在装箱单外面，哪些不应该在，最终会确定好一个装箱单。
- 当迭代周期开始之后，研发就开始依照装箱单外面的性能进行开发，每一个性能都有一个 owner，项目经理会每周跟这些 owner 散会来对齐进度。发版经理会跟大家明确好性能的 GA 规范，以及整个版本的 GA 规范。
- 当迭代周期进入序幕，发版经理就会开始解冻分支，发出代码权限，这时候大家就进入全面测试阶段（当然，日常开发过程中咱们也会进行大量的测试）。
- 当分支被解冻后，对于测试发现的 bug，发版经理会每天跟大家进行一次 bug traige，来确定这些 bug 是否应该进入这个版本，还是先不必管。
- 每周发版经理会组织大家进行一次 war meeting 会议，来探讨以后版本的状态，以及评估是否能发版，或者是延期。
咱们当然心愿能失常按时发版，但软件工程你懂的，现实很美妙，事实很骨感。不过好在咱们就 2 个月的迭代周期，布局的事件比拟少，还比拟可控，所以通常延期的危险就比拟小。另外，下面这个流程我并没有提到如何跟社区单干，让社区的奉献带人到版本外面，这个前面我会介绍。
但咱们不会就此满足，2 个月对咱们来说就相似于中国的绿皮火车，咱们的指标是变成中国的高铁。所以如果你在 DevOps 等方面有丰盛的教训，让 TiDB 可能随时高质量发版，欢送分割咱们。
异步工作和 wiki
作为一家开发分布式数据库的公司，咱们本身也在践行全球化的分布式办公，咱们的研发团队是扩散在不同地点，不同时区的，在这种状况下，基于 IM 的同步工作形式就不起作用了，所以咱们在开始探寻更好的异步工作形式。要做到异步工作，一个十分直观的转变就是大家要将本人的工作上下文具体的记录到文档外面，这样其他同学就能疾速的理解你的工作。所以咱们重度依赖 Google doc，Jira，Github 等工具。
另外，PingCAP 从开始就应用的 Google 全家桶，所以咱们的研发文档资料是全副在 Google drive 外面的，但大家也晓得，Google drive 其实并不是一个很好的材料治理汇总的工具，但因为咱们之前大量的数据曾经在这边了，短期也不想迁徙，所以为了晋升咱们应用 Google drive 的效率，以及更好的对咱们所有的材料进行治理，咱们基于 Google drive 开发了 PingCAP 本人的 wiki 零碎。
有了 Wiki，一个直观的益处就是一方面咱们能很不便的持续应用 Google 全家桶，另外，也很好的解决了咱们材料共享，合作的问题。前面，等咱们梳理好文档的权限之后，咱们也会将这个 Wiki 开发给社区，能让社区间接拜访任何咱们想公开的信息。
当然，鉴于 PingCAP 是一家天生喜爱开源的公司，咱们天然也开源了这套 wiki 零碎，大家能够拜访 https://github.com/pingcap/gdocwiki 理解更多。这套零碎并不一定是最高效的，只是现阶段对咱们够用了。
防火墙和 resilience
之前，咱们的研发工程师会解决太多的事件，不光要写代码，还得去做很多额定的事件，尽管我认为 PingCAP 的工程师是世界顶尖的人才，但一个人无论再怎么厉害，如果让他同时做多件事件，就会相似 CPU 频繁的进行 context switch，看起来很繁忙，但理论效率很低。
所以，咱们成立一个了虚构的防火墙 team，来隔离内部跟研发同学的间接对接。这个 team 每一段时间会有几名同学全职在外面，他们的责任就是最大化的保障其余研发同学不被打搅，能安安心心写代码，所以在这个 team 外面的同学压力会十分的大，他们不光要解决所有转交给研发的客户的线上问题，去会去帮忙业务去反对客户的 PoC，甚至去给客户培训等等，尽管大家都是轮值，但一轮下来，真的有时候会累的脱层皮。
为了更好的晋升防火墙的效率，咱们在之后成立了一个虚实联合的 resilience team，这个 team 不光要做后面防火墙 team 做的事件，还做了更多的事件，包含但不限于剖析故障解决记录，提炼产品的改良点，构建用户视图，对重要客户全程跟进，晋升客户服务品质等。这也是一个神奇的 team，如果可能，我前面会专门介绍下这个 team 干的乏味的事件。
Bug jail
光有火车发版模型还不够，在下面提到，咱们引入这个模型，次要是管制两个点，一个是发版的节奏，另外一个就是产品的品质。要保障高质量，在架构下面要足够简略，写代码要思考边界异样解决，review 代码要仔细认真，写足够的测试等等。
这里，我跟大家讲讲咱们设计的一个小游戏，来晋升大家对品质的器重。作为一位研发同学，我其实十分能了解，大家迫切想写代码，开发新性能的志愿，但面对品质问题，一律得停下来。咱们在 PingCAP 创立了 bug jail 机制，如果一位同学被调配的要修的 bug 太多，或者某个模块被测进去的 bug 太多，这位同学或者这个模块对应的 team 就会被强制进入 bug jail 外面，在 jail 外面的同学只能修 bug，不能再开发新的性能，除非他们把 bug 给修到某一个阈值以下。
当然，除开 bug jail，咱们还做了很多其余工作来保障咱们产品的品质，咱们也对外输入了很多先进的测试理念，甚至开源了出名的混沌测试平台 ChaosMesh®，前面我也会具体在说说 PingCAP 的质量体系。
写在最初
当然，下面只是大略介绍了一些点，前面我还会介绍的更多，譬如咱们的 CICD 零碎，咱们的 telemetry，dashboard 等，我心愿能让大家更好的去了解 PingCAP 的工程体系。
知乎下面有一个帖子，做数据库内核开发的是不是很少，据我所知，至多在中国，这块的人真的是非常少，因为要做一个数据库真的是太难了。对于 TiDB 来说，咱们不光有技术下面的挑战，还有开源单干，生态整合，云上云下，全球化，近程办公等，我甚至认为，开发 TiDB 在软件工程畛域都是一个值得钻研的案例，这也是为啥我想把咱们如何来开发 TiDB 的一些根本的货色写下来的起因。
PingCAP 花了整整六年，才有了当初的成绩，在将来，咱们的挑战会更大，如果你也是那种想挑战世界顶级难度工作的同学，欢送分割我，我置信，每一次 TiDB 大版本的公布都是一次见证奇观的过程，将来让咱们一起来一直的发明新的奇观。我的邮箱 tl@pingcap.com，微信 siddontang。