本投稿はFlutter Advent Calendar 2024の16日目の記事です

今プライベートでFlutterを触っていてプロジェクトを作る際にまずセットアップしたことがいくつかあるのでまとめます。 Flutterはほとんどやったことがなく、普段はKotlinでAndroidアプリを書いています。

そんなFlutter初心者が書いた内容ですが、ほとんどのことはFlutterに限らず他のフレームワークや言語、プロジェクトでも共通している内容となった気がします。

CodeRabbitの設定

CodeRabbitは、AIがコードレビューしてくれるツール・サービスです。コードレビューだけじゃなく、PRの内容のサマリーなども自動で書いてくれます。

Flutterを学び始めで自分が書いたコードが果たして良いのか悪いのか……客観的意見が欲しいものですが、個人開発でレビューしてもらう機会などありません。が、CodeRabbitならAIがレビューしてくれるので、フィードバックをもらえます。

内容のサマリーも書いてくれるので、レビュー目的じゃなくても使えそうです。

GitHub Actionsの設定

Linterや自動テストなど、開発が進む前にプロジェクト作成をしたらまず設定しておきたいです。 CI/CDはGithub Actionsを採用します。

Linter

標準で入っている flutter_lintを使います。他にも有名らしい very_good_analysis などがあるらしいですが、1人開発なのでどのLinterがいいか比較はしていません。

analysis_options.yamlに有効にするルールをセットします。

include: package:flutter_lints/flutter.yaml

linter:
  rules:
    avoid_print: true # 本番環境でprintしない
    prefer_single_quotes: true # エスケープの必要がないなら シングルクォーテーションを使う
    always_use_package_imports: true # ファイルの相対インポートは避ける
    avoid_annotating_with_dynamic: true # dynamic必要ない場合は注釈を付けない

そして静的解析をGitHub Actionsで実行するように設定します。

      - name: Linter
        run: flutter analyze

自動テスト

テストもflutter testを使います。

後述の通りカバレッジを取るので --coverage をつけます。

      - name: Test
        run: flutter test --coverage

カバレッジレポート

テストのカバレッジを取ります。 PRにプッシュされたら、カバレッジレポートをPRに自動でコメントするように設定します。

octocov

PRへの自動コメントはoctocovを使います。 codecovとかとは違い、サービス連携などは不要でGitHubで完結できるツールです。

パーミッション設定

Github Actionsのジョブ中にprへコメントするためにパーミッショの設定が必要です。これしないとoctocovがコメントできないです。

「Settings」>「Actions」>「General」>「Actions permissions」>「Workflow permissions」> 「Read and write permissions」

renovate

ライブラリの更新も自動化しちゃいます。renovateでパパッと設定します。

パッケージ管理は特にこだわりなく「pub」にしているので、renovate.jsonをpubに合わせてあげます。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "enabledManagers": ["pub"],
  "packageRules": [
    {
      "matchManagers": ["pub"],
      "automerge": false
    }
  ],
  "prConcurrentLimit": 3
}

マージされたPRのブランチは自動削除

あとは、ブランチがどんどん増えていかないように、マージされたブランチは自動で削除もしておきます。

「Settings」 > 「Pull Requests」 > 「Automatically delete head branches 」

device_previewの設定

device_previewという様々な環境でPreviewの確認ができるライブラリを入れてます。

dependencies:
  flutter:
    
    device_preview: [バージョンを指定]

import 'package:device_preview/device_preview.dart';

void main() {
  runApp(
    DevicePreview(
      enabled: !kReleaseMode,
      builder: (context) => MyApp(), // Wrap your app
    ),
  );
}

プロジェクト

こちらに内容を置いています。

github.com

おまけ

1人で開発前提だったので見送りましたが、チーム開発や業務なら以下も設定していたかもです。

ブランチ保護

個人のリポジトリなのでブランチ保護はしてませんが、業務でチーム開発などならしたかもです。

ブランチ戦略

とりあえず mainから作業ブランチ切ってPR出してマージしてってしてますが、チーム開発ならブランチ戦略も考えたいところです。概ね、Github Flow か Git Flow などをベースとして業務フローや規模に合わせた形になると思います。

自動ビルド配布

1人なのでしてませんが、チーム開発や業務で他職種のメンバーや社内に向けて常に最新のアプリを配布するとかであれば設定しておくといいと思います。開発中のものでも簡単に共有できます。

モバイルだとFirebase App DistributionやDeploy Gateがまず思いつきます。

リリース運用

初回リリースできる時に考えたり設定すればいいですが、リリース運用も考えておくと楽そうです。何かをトリガーにCIで自動でリリースを作ったり、タグを作ったり、バイナリ(aabなど）をGoogle Play Consoleへ自動でアップロードしたり。

バージョン戦略

大体、x.y.z の形式で x: メジャー、 y: マイナー、 z:パッチだと思いますが、どういう内容でどの位をインクリメントするのか。人によって解釈変わると思うので、チーム開発なら共通認識持つと良さそうです。

ビルドタイプ設定

Androidだとデフォルトでdebug, releaseがあるのでそれで事足りるならいいですが、業務だと環境がいくつもあってそれごとにビルドタイプ分けるなども考えられます。インストール時に見分けがつくように、アイコンをちょっとだけ変えたり、アプリ名を変えておくとわかりやすいです。

VRT / スクリーンショットテスト

Visual Regration Test とかスクリーンショットテストとか。 1人でもあってもいいかもと思っているので、後で導入するかも。

kako.dev

開発、自作アプリのこと

個人開発のFlutterプロジェクトを作成してまずしたこと