おはようございます。この連載も、いよいよ最終回です。
振り返ると、「教える」というより「自分自身が学び直す記録」として始めたこの6回、最後は少しだけ背伸びして、CI/CD（継続的インテグレーション）の入り口を覗いてみようと思います。
「コードをプッシュしたら自動でテストが走る」仕組み
ここまでの回では、flutter analyze や flutter test を、自分のパソコンで手動で実行する前提で進めてきました。
でも実際には、「テストを実行し忘れたままプッシュしてしまった」「analyzeでエラーが出ているのに気づかず進めてしまった」ということも起こります。
GitHub Actionsは、GitHubにコードをプッシュしたタイミングで、決められた作業（テストの実行など）を自動的に行ってくれる仕組みです。人間が「テストを実行するのを忘れる」ということ自体をなくせるのが、いちばんの利点です。
初心者向けのシンプルなWorkflow
GitHub Actionsの設定は、リポジトリ内の .github/workflows/ というフォルダに、YAMLというファイルを置くことで行います。
まずはこのフォルダとファイルを作成します。
mkdir -p .github/workflowsそして .github/workflows/flutter-ci.yml という名前で、以下の内容を作成します。
name: Flutter CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: subosito/flutter-action@v2
with:
flutter-version: '3.44.7'
- run: flutter pub get
- run: flutter analyze
- run: flutter test内容をざっくり説明すると、
on:の部分で「いつ実行するか」を指定しています。ここではmainへのプッシュと、Pull Request作成時に実行される設定ですsteps:の部分が実際の作業内容で、コードを取得 → Flutter環境を準備 → 依存パッケージを取得 →flutter analyze→flutter test、という流れです
このファイルをコミット・プッシュすると、GitHubのリポジトリ画面にある「Actions」タブで、自動テストの実行結果を確認できるようになります。テストが通れば緑のチェックマーク、失敗すれば赤いバツ印が表示されるので、一目でわかります。
pubspec.lock はGit管理に含めるべき？
Flutter特有の疑問として、pubspec.lock を .gitignore に入れるべきか迷う方もいるかもしれません。
結論としては、アプリ開発の場合は pubspec.lock もGit管理に含めるのが基本です。これは「使用しているパッケージのバージョンを固定する」ためのファイルで、これを含めておくことで、自分の環境でもGitHub Actions上でも、同じバージョンのパッケージで flutter test が実行されるようになります。もし含めていないと、CI上だけ違うバージョンのパッケージが使われてテストが失敗する、といったことも起こり得ます。
（ライブラリ・パッケージ自体を作っている場合は事情が異なりますが、アプリ開発ではまず「含める」で問題ありません。）
連載を終えて
第1回で「Gitはタイムマシン」という話から始まり、.gitignore、ブランチ、APIキー管理、Issues/Projects、そして今回のGitHub Actionsまで、一通りの基礎を駆け足で回ってきました。
正直なところ、自分自身「なるほど、そういうことか」と腑に落ちながら書いた部分も多い連載でした。
ここまでお付き合いいただき、ありがとうございました。
