文章目录
原文地址: https://github.blog/2022-01-12-how-we-ship-github-mobile-every-week/
本博客站点已全量迁移至 DevDengChao 的博客 https://blog.dengchao.fun , 后续的新内容将优先在自建博客站进行发布, 欢迎大家访问.
正文
每周,GitHub Mobile 团队都会更新 iOS 和 Android 上的 GitHub Mobile 应用程序,包括新功能、错误修复和改进。
然而发布移动应用程序并非易事。
在将构建产物交付给用户之前,我们必须确保能够正确地构建产物,所有现有的测试都已通过,并且任何关键问题都被通过测试阶段捕获。 此外,我们还需要编写自上次更新以来包含的更改的发行说明。
所有这些任务都可能非常耗时。
由于我们是一个小团队,每周重复这个发布过程意味着更少的时间花在编写代码或构建新功能上。为了专注于产品开发,我们使用了许多工具来自动化发布过程。 在这篇文章中,我将通过使用 iOS 工作流作为示例来分享我们如何构建自动化发布过程。
当满足以下条件时,一个发布候选版本就可以发布给我们的 beta 测试用户了:
- 创建一个分支来紧急修复候选发布版可能出现的问题
- 使用正确的版本号进行构建并将产物上传到 TestFlight
- 所有单元测试和快照测试均已通过
- 创建一个 Issue 来跟踪发布过程
- 发行说明已准备就绪
GitHub 为持续集成和交付提供了出色的工具。我们主要使用 GitHub Actions 来自动化大部分步骤以满足我们的标准,偶尔需要借助一些额外的工具,例如 fastlane 。
上图说明了使构建准备好发布的整个过程。灰色步骤由 GitHub Actions 自动执行,而蓝色步骤由我们的团队手动处理。
如图所示,大部分步骤都是自动化的。只有最后的步骤,例如合并与发布相关的更改或完成应用程序提交,需要人工交互。 我们手动编写发行说明,因为人类在编写散文方面仍然比机器好,但是材料是由自动化准备的,因此写作过程并不是很耗时。
接下来让我们来深入地了解一些细节。
构建和发布 (Build and release)
首先,我的团队需要为任何给定的构建生成一个应用程序二进制文件。 我们定义了一项作业,其中包含生成构建、检查测试用例、归档和上传到 TestFlight 的多个步骤。
我们为我们发布的每个版本创建一个专用分支,以便我们可以返回并挑选我们想要包含的任何更改。 GitHub Actions 拥有强大的社区支持,我们可以使用大量开源 Actions。
例如,peterjgrainger/action-create-branch Action 可以轻松创建新的发布分支。
创建分支后,我们将进行 fastlane 构建、测试、归档和上传。 为了对二进制文件进行代码签名并将其上传到 TestFlight,我们的操作将需要证书和凭据来运行这些安全且经过身份验证的命令。
这些凭据存储在 GitHub Secrets 中,你可以轻松地将它们传递到 Action 中,而不会将它们泄露给潜在的攻击者。
创建问题 (Issue creation)
一旦创建好 Issue 并将二进制产物上传到 TestFlight,我们就开始另一项工作。
这会创建一个 GitHub 问题来跟踪分发构建所需的任何文书工作或手动过程。 该问题作为一个剧本,包含向我们的用户提供发行版的所有步骤,包括验证发布营销材料、发布前手动测试,甚至与团队共享状态。
通过遵循这个剧本,发布队长不需要记住任何步骤,任何新人都可以在没有什么培训的情况下成为发布队长。
通过在 GitHub Actions 工作流 YAML 文件中添加一个 shell 命令,可以使用GitHub CLI轻松完成 Issue 的创建,例如 gh issue create -t {title} -b {body} -a {assignees} -l {labels}
.
此外,还有许多开源 Action,例如 JasonEtco/create-an-issue ,这使得通过模板创建问题变得容易。
我们使用 PagerDuty 管理发布工程师的轮换。 为了通过 PagerDuty API 获取下一个发布工程师,我们还利用了其他的开源操作,例如 JamesIves/fetch-api-data-action.
然后将发布队长分配给这个 Issue,以便我们都知道谁在负责此次发布任务。
发行说明 (Release note)
在另一项并行工作中,我们需要准备材料以撰写发行说明。
通过使用 fastlane
命令,我们收集自上次发布以来已推送的所有提交(或者,您可以尝试最近添加到 GitHub 的另一个自动化 )。
更改日志是所有提交和拉取请求 (Pull Request) 的原始记录,这意味着这些文本并不适合作为直接面向我们用户的发行说明。
因此,我们在我们的仓库中创建一个包含这些原始更改日志的文本文件,并打开一个拉取请求,我们可以在其中编写更简单易懂的发行说明。
使用 GitHub CLI 打开拉取请求非常简单。添加一个 shell 命令,gh pr create -t {title} -b {body} -a {assignees}, -r {reviewers} -l {labels}
将自动创建一个拉取请求作为作业的一部分。
诸如此类的开源操作 peter-evans/create-pull-request 也能快速地创建一个拉取请求。
我们找到下一个发布工程师(使用与我们在创建问题时找到一个工程师相同的方式)并将工程师分配给这个拉取请求。
一旦工程师完成了对客户友好的发布说明并且另一个团队成员审核了这些更改日志,我们将合并拉取请求以将其存储在我们的仓库中。
版本号管理 (Version number management)
我们还有另一个并行工作来管理构建版本号。
一旦创建了候选发布版本,我们就会在 main
分支上迭代版本号以便每个人都可以进入下一个发布周期。
为防止出现任何错误,我们不会将任何代码更改直接推送到 main
分支中。
相反,版本更新是使用小型 Bash 和 Ruby 脚本完成, 迭代版本号更新的拉取请求则是由 Action 创建。
上图所描述的四个作业及其所有步骤都定义在一个 YAML 文件中,该文件定义了 GitHub Actions 工作流程。
工作流程在每周六早上开始,以便发布工程师在周一到来时拥有所有材料。
周一早上,工程师勾选了工作流创建的问题中描述的所有步骤,将构建发送给我们的 TestFlight beta 用户,然后最终提交给 App Store 审查。
在这一周内,我们会监控 beta 测试的进展情况。如果我们从构建中发现了关键问题,我们会在 main
分支上修复它,然后将修复程序挑选 (cherry-pick) 到发布分支中,然后重新上传一个构建版。
(我们有另一个 GitHub Actions 工作流,它可以自动执行这个额外的构建过程,每当我们将代码更改推送到发布分支时就会触发这个过程。)
如果本周的 beta 指标看起来不错,没有崩溃的话,我们就会在它开始 beta 测试一周后将其发布到 App Store 。
通过这种方式,我们的客户每周都能获得可靠的 GitHub Mobile 更新。
结论
在这篇文章中,我描述了我们如何通过使用 GitHub Actions 实现的构建发布流水线实现每周发布 GitHub 移动应用程序。
GitHub Actions 的社区支持令人惊叹,有很多强大的开源操作可供您立即使用。如果您想拥有自己的自定义操作和工作流程,也很容易创建一个并在存储库或项目中重复使用它。
由于 GitHub Actions 支持的自动化大大改善了我们的发布流程,使我们有更多的时间和精力专注于产品开发,并花费更少的时间等待 Xcode 编译。
通过 GitHub Actions 和 GitHub Issues 自动化我们的发布流程,使得新的成员作为发布工程师加入团队并每周将他们的新功能发布到 App Store 变得容易得多。
我希望这篇文章可以帮助那些想要使用 GitHub 工具构建可靠的 CI/CD 流水线的人。
要了解有关使用 GitHub Actions 自动化发布过程的更多信息,请查看以下资源:
- 加入 Beta 计划
- GitHub Actions
- GitHub CLI
- GitHub Secrets
- 在 GitHub 上自动生成发行说明
- fastlane
- peterjgrainger/action-create-branch
- JasonEtco/create-an-issue
- JamesIves/fetch-api-data-action
- peter-evans/create-pull-request