发布工程的基本思想之三（测试、打包、部署）
分支所有的代码都默认提交到主分支上（mainline）。然而，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug 修复先提交到主分支，再cherrypicking到发布分支上。这种方式可以避免在第一次构建之后，再引入主分支上的其他的无关改动。利用这种分支与cherry picking 的方法，可以明确每个发布版本中包含的全部改动。测试一个持续测试系统会在每个主分支改动提交之后运行单元测试，这样我们可以快速检测构建错误和测试错误。建议使用项目中定义的构建目标及测试目标的执行结果来决定是否发布某个版本。同时建议使用最后一个测试全部通过的软件版本来进行最新的发布。这些方法可以降低在真正发布时由于主分支上其他无关改动造成问题的几率。
在发布过程中，我们会使用该发布分支重新运行全部单元测试，同时为测试结果创建审核记录。这一个步骤非常重要，因为如果一个发布过程需要cherry picking，发布分支可能会包含主分支上不存在的一个代码版本。我们必须确保在发布分支上全部测试确实通过。
为实现持续测试系统，我们使用一套独立的测试环境来在打包好的构建结果上运行一些系统级别测试。这些测试可以从 Rapid 网站上手工启动。
打包软件通过Midas PackageManager（MPM）系统分发到生产机器上。MPM基于Blaze 规则中列出的构建结果和权限信息构建 MPM包。每个包有固定名称（如search/shakespeare/rontend），记录构建结果的哈希值，并且会加入签名以确保真实完整性。MPM 同时支持给某个版本的包打标签。Rapid也会加入一个构建ID 标签，这样某个包可以用名字和这个标签来唯一识别。
我们可以给某个MPM包加标签，标记该MPM包在整个发布过程中的位置（如dev、canary 或production等）。如果将某个现有标签应用到新包上，这个标签会自动从原来的包上移除。例如，如果一个包标记为 canary，之前的 canary包上的标签就被自动去掉了，后续安装 canary 版本的包的人会自动使用最新的包版本。
页:
[1]