flutter-ci-cd

Flutter CI/CD

リポジトリの既存のデリバリーモデルに沿って、再現可能なパイプラインを構築します。移行が明示的に求められていない限り、現在のプロバイダー、Flutter バージョンの取得元、パッケージマネージャー、フレーバー、署名フロー、デプロイツールを維持してください。

事前確認

パイプラインの変更を行う前に、pubspec.yaml、ロックファイル、SDK／バージョンマネージャーのファイル、ワークスペースの構成、生成コードの方針、フレーバー、テスト、ネイティブターゲット、既存のパイプラインファイル、リポジトリのスクリプト、リリースツール、保護された環境、シークレット名を確認してください。信頼性や速度を診断する際は、実際のジョブ依存関係グラフと、直近の所要時間／失敗ログを調べてください。リポジトリの根拠を確認できない場合は、必要なファイルやログを正確に指定して依頼または列挙し、一般原則の範囲で助言してください。プレースホルダーのワークフローを、修正済みのものとして提示してはいけません。署名素材やサービス認証情報を表示、移動、生成、コミットしてはいけません。

プルリクエストの信頼性確認とリリース権限を分けてください。CI ジョブの成功によって確認できるのは、チェックやアーティファクトの作成までです。タグ付け、ストアへのアップロード、本番デプロイ、認証情報の変更は許可されません。

作業の振り分け

• 決定論的なフォーマット、解析、コード生成、テスト、カバレッジ、ゴールデン、マトリックス、キャッシュのゲートについては、品質ゲートを確認してください。
• 署名、シークレット、アーティファクト、シンボル、保護された環境、段階的ロールアウト、公開の境界については、デリバリーとシークレットを確認してください。
• GitHub Actions、GitLab CI、Codemagic、Bitrise、Xcode Cloud、モノレポ、プロバイダーを維持する判断については、プロバイダーとモノレポを確認してください。

現在のパイプラインに必要な参照資料だけを読み込んでください。

境界

• flutter-build-release は、フレーバー、署名設定、バージョン管理、シンボルの生成、ストア提出可能なローカルアーティファクトを担当します。プロバイダーの YAML 内で再実装するのではなく、確立済みのコマンドを確認して実行してください。
• flutter-testing はテスト戦略とテスト実装を担当します。このスキルでは、リポジトリで選択されているテストスイートをゲートとして実行します。
• より広範なセキュリティ監査は flutter-security が担当します。このスキルでも、最小権限、シークレットの分離、信頼できる依存関係のピン留め、信頼されていないフォークの境界を適用してください。
• パイプラインを作りやすくするために、アプリケーションのアーキテクチャ、状態管理、パッケージを変更してはいけません。

検証

プロバイダーが現在提供しているリンター／ドライラン機能で構文を検証し、環境が許す範囲ですべての基盤となるリポジトリのコマンドをローカルで実行してください。キャッシュのない場合とある場合、プルリクエストと保護ブランチの条件、期待されるアーティファクト、キャンセル／並行実行の動作、失敗の伝播を確認してください。キャッシュのヒットとミスで、同じ正しさが得られなければなりません。フォーマットおよびゴールデンのゲートによって、ソースや期待値が書き換えられてはいけません。鮮度チェックでは、使い捨てのチェックアウト内で既定のジェネレーターを実行してもかまいませんが、差分が生じた場合は失敗させ、その差分をコミットしたり隠したりしてはいけません。デリバリーでは、許可された外部変更を行う前に、ドライランまたは本番以外のターゲットを優先してください。

変更したコマンドとパイプラインのパス、検証した環境、アーティファクトの証拠、macOS ランナー、署名、シークレット、クォータ、ストア側の制約を報告してください。パイプラインを成功させるためだけに、ゲートを弱めてはいけません。

参考資料

• Flutter による継続的デリバリー
• Flutter アプリのテスト
• GitHub Actions のセキュリティガイダンス