版本发布推广¶
版本发布推广允许我们交付与之前已测试的编译二进制文件相同的版本。
在过去,我们习惯使用单独的配置重新编译发布版本,这导致了一些在持续集成测试中未捕获的发布特定错误。这意味着我们需要在发布时进行新的构建,这大大增加了特定发布的端到端时间。版本发布推广消除了这些反模式。
通过对可交付构建运行持续集成测试,我们在发布时拥有了更高的信心。通过将构建阶段任务(编译、打包和相关测试)与推广阶段任务分离,我们可以根据需要以各自独立的节奏安排每个阶段,并且推广的端到端时间大大缩短。
版本发布推广阶段¶
目前,我们有 build
、promote
、push
和 ship
阶段。
build
阶段创建 shippable builds
。这些构建优先考虑正确性而不是速度,旨在达到发布质量,以便我们决定是否发布该代码修订版。这些构建在发布分支上的推送操作时触发。(我们还在大多数分支上安排了 depend
构建,这些构建优先考虑速度而不是正确性,以便我们能够更早地检测到新的代码问题。)
promote
阶段对可交付构建进行本地化,创建任何更新 MAR,并在 S3 上填充候选目录。(在 Android 上,我们重新构建,因为我们尚未成功重新打包 APK。)
push
阶段将候选文件推送到 S3 上相应的发布目录。
ship
阶段向用户交付或安排更新。这些更新通常以有限的推广比例进行,或者取决于多个下游签核才能完全交付。