Tubi 的一个目标是 “Stream anywhere”，也就是让用户可以随时随地用任意设备观看我们的电影和剧集。目前 Tubi 的应用已经出现在超过一百种设备上，包括网页、移动端、电视、蓝光播放器、游戏主机、机顶盒，以及像 Roku 和 Fire TV 这样的 OTT 流媒体设备。伴随着如此庞大的一个生态系统，以及相对有限的资源，想要保持一个快速迭代和发布的节奏对我们来说是一个非常大的挑战。在这篇文章中，我们会讨论我们具体遇到的问题，以及我们是如何借助 Hubble —— Tubi 内部的发布管理工具来解决它们的。
维护多平台的挑战
作为一个团队，保持信息同步是很重要的，比如最近发布了什么新的特性，哪些还在开发中，有哪些关键性阻碍等等。然而拥有如此多的平台，即便它们有 80% 以上的代码是共享的，也很难了解其中每一个的最新进展。经常会出现这样一种情况：一个团队成员想了解某一段特定的代码是否已经在某一个特定的平台上线，他们必须去各种 git hash 和 commit 中寻找或者去问负责的工程师。除此以外，每当一个平台的发布完成，相关的工程师会需要周知各种人（产品、测试等等），告诉他们这次发布涉及的改动来协助他们进行回归测试。这种协作所需要的人工成本是比较高的，并且还有一定的沉没成本——本应可以用来提升我们产品的时间也被这些人为的打断所占用了。
Hubble 的诞生
我们迅速地意识到应该有一个服务来收集、组织以及展示这些发布相关的有用信息，于是开始着手搭建 Hubble 这个发布展示平台。对于 Hubble 来说，最重要的事情就是定义一个发布版本的实体是什么。总的来说它包含三部分：
-
首先，一个发布版本应该包含 git 的改动历史。只要一个版本被生成出来，那么 Hubble 就会比对出这个版本和上一个版本的差异，并使用中间的 git messages 生成 changelog，这样工程师就不用自己去写了。
-
其次，为了使版本的 changelog 对于非工程师团队也同样易读，Hubble 把每一个 Github 的 pull request 都与 Clubhouse（项目管理平台）里面的 stories 一一对应。比起 git message，story 的信息会更加贴近于产品的角度，并且拥有更多的细节，让非工程师团队的成员也比较容易理解。对于每个发布版本 Hubble 都会从 Clubhouse 上拉去对应的信息，并最终生成一个对于这个版本所包含的 stories 列表。
-
最后，Hubble 还会生成一个 “QA notes” 的列表。我们发现很多时候，无论是 commit messages 还是 story 的描述信息都没有完全涵盖某个改动的影响范围。在 Tubi，如果一个 pull request 需要有一些特别的点需要在回归测试中注意，我们鼓励工程师在 merge 的时候写一些提示。Hubble 会把这些提示收集起来，作为另外一个列表展示出来。
Hubble 是如何与我们现有架构集成的
要让 Hubble 运转起来，最开始我们需要简单快速地在其中定义一个项目。填写几个必要的信息：名称、Github URL 以及当前线上版本的 git hash。剩下的就都交给 Hubble 了，包括收集每次发布版本的信息、对不同版本进行比较、展示相关数据等等。下一步 Hubble 会从不同团队和项目中拉取新的版本进来。在 Hubble 中有两种方式—— REST API 和 Github Releases 的同步服务。在 Tubi，我们对各个项目会使用同一套基于 Ansible 的发布机制，这使得我们可以很简单的将 Hubble 集成进来。只要在 playbook 的结尾调用 Hubble 的 API，就可以基于本次发布动作为项目创建一个新的版本。
Tubi 所有的团队，甚至包括后端团队，都很快地适应了 Hubble，并开始使用它来管理自己的发布版本。
利用自动化去解决痛点
目前 Hubble 已经不只是一个发布版本的展示平台，它已经参与到了开发流程的各个环节来提升效率。
及时恰当的发布周知
为了降低发布的沟通成本，使工程师不再需要自己再去告知其他人，我们将 Hubble 集成到了 Slack。团队里的任何人都可以通过简单的命令来订阅任意一个项目的发布信息。当有新的版本出现时，Hubble 会将其链接推送给订阅的人和群组。
避免未告知的测试环境覆盖
在 Tubi 我们使用与生产环境对应的测试环境来进行开发和集成测试。在过去我们会对谁在使用哪个测试环境特别地进行沟通，但还是会出现互相之间不经意的覆盖。有了 Hubble 之后，每一次测试环境的发布都会被记录，并且团队中的成员会接收到提示，哪台机器的使用者刚刚发生了变化。这样我们就不必担心测试环境在不被告知的情况下被覆盖了。
CI 平台的补充
Tubi 借助 CI 环境来执行构建、自动化测试，以及其他一些工程任务，但是其中有一些是 CI 无法很好完成的。比如说，我们会对客户端项目的每一个 pull request 跑 Lighthouse 性能分析。虽然有用，但是通过这种方式得到的评分及相关数据并不能直接体现出该 pull request 所带来的影响。为了解决这个问题，我们在 Hubble 中添加了一项特性，比较不同的 Lighthouse 报告并且将得到的差异发送给 Github 对应的 pull request 页面。这样我们就可以知道这些改动对性能带来了正面还是负面的影响。
本文作者 Yuhao Ju，Tubi Senior Web Engineer
小结
工具并非银弹，但是好的工具可以带来截然不同的开发体验。随着 Tubi 团队的日益扩大，我们将会持续地寻求保持高速迭代的方法。我们非常重视为工程师提供一个高效的开发环境，如果你也对此感兴趣，那就加入我们吧！
