flutter-ci-cd

Flutter CI/CD

围绕仓库现有的交付模式构建可复现的流水线。除非明确要求迁移，否则保留当前的服务提供方、Flutter 版本来源、包管理器、flavor、签名流程和部署工具。

预检

在编写流水线变更前，先查看 pubspec.yaml、锁定文件、SDK/版本管理器文件、工作区布局、生成代码策略、flavor、测试、原生目标、现有流水线文件、仓库脚本、发布工具、受保护的环境和密钥名称。诊断可靠性或速度时，检查实际的作业依赖图以及近期的耗时/失败输出。如果无法获取仓库证据，请索取或列出所需的确切文件和日志，并将建议限定在不变量层面；不要把占位工作流说成已完成的修复。绝不打印、移动、合成或提交签名材料或服务凭证。

区分拉取请求的可信度与发布权限。通过的 CI 作业可以证明检查和构建产物已完成，但不代表获得了创建标签、上传到应用商店、部署到生产环境或更改凭证的授权。

确定工作方向

• 对于确定性的格式检查、分析、代码生成、测试、覆盖率、golden、矩阵和缓存门禁，请阅读质量门禁。
• 对于签名、密钥、构建产物、符号文件、受保护的环境、分阶段发布和发布边界，请阅读交付与密钥。
• 对于 GitHub Actions、GitLab CI、Codemagic、Bitrise、Xcode Cloud、单体仓库和保留服务提供方的决策，请阅读服务提供方与单体仓库。

仅加载当前流水线所需的参考资料。

边界

• flutter-build-release 负责 flavor、签名配置、版本控制、符号文件生成和可供应用商店提交的本地构建产物；应检查并编排这些既有命令，而不是在服务提供方的 YAML 中重新实现。
• flutter-testing 负责测试策略和测试实现；此技能负责将仓库选定的测试套件作为门禁运行。
• flutter-security 负责更广泛的安全审计；此技能仍须遵循最小权限原则、隔离密钥、固定可信依赖项，并划定不受信任的分支边界。
• 不要为了让流水线编写更方便而更改应用架构、状态管理或包。

验证

使用服务提供方当前的 lint/试运行工具验证语法，并在环境允许时于本地运行所有底层仓库命令。检查冷启动和缓存路径、拉取请求和受保护分支条件、预期构建产物、取消/并发行为以及失败传播。命中缓存和未命中缓存必须产生相同的正确性结果。格式和 golden 门禁不得重写源代码或预期结果。新鲜度门禁可以在一次性检出中运行既有生成器，但必须在产生差异时失败，且绝不能提交或隐藏该差异。对于交付，任何获准的外部变更之前，优先选择试运行或非生产目标。

报告变更的命令和流水线路径、已测试的环境、构建产物证据，以及任何 macOS 运行器、签名、密钥、配额或应用商店侧的缺口。绝不要仅为让流水线通过而降低门禁标准。

来源

• 使用 Flutter 持续交付
• 测试 Flutter 应用
• GitHub Actions 安全指南