【Flutter】プロダクト運用時に設定するアレコレ
heyhey1028目的
プロダクトやサービスを業務用に運用する際に下準備として設定するアレコレを整理する。
- Linter
- Danger
- Formatter
- LeftHook
- Test
- codecov (test)
- reg-suit (VRT)
- maestro cloud (E2E)
- PR運用
- Git commit hooks
- PRテンプレート
- githubのPRルール
- PRに対するAIレビュー
- 分析基盤
- Analytics
- Crashロギング
- 操作ロギング
- メトリクス
- 多言語対応
- アイコン・スプラッシュ
- スプラッシュ画面の設定
- アプリアイコンの設定
- プッシュ通知アイコンの設定
- バージョン管理 (fvm, asdf)
heyhey1028[Github]ブランチ保護ルールの設定
heyhey1028[Flutter/Dart]静的解析のセットアップ
アプリを実行する前にコードが望む形になっているかを解析する事を静的解析と呼びます。その設定を記述されるのが analysis_options.yaml です 。
analysis_optionは主に LinterとAnalyzerという２つのパートで構成されています。
AnalyzerはソースコードにDartの言語仕様で指定されているエラーや警告などの潜在的なバグがないかを解析します。LinterはソースコードがDartのスタイルガイドラインや設定した他のガイドラインに準拠しているかを解析します。
Linterに関しては１つ１つ必要なルールを追加することも可能ですが、必要なルールをまとめたパッケージを導入することで手間を省くことが出来ます。これらはanalysis_optionsにinclude句を記述する事で追加します。
analysis_options.yaml
LinterとAnalyzerとLinterパッケージは以下のように記述します。
include: package:flutter_lints/flutter.yaml
analyzer:
exclude:
- "**/*.freezed.dart"
- "**/*.g.dart"
- "lib/generated/**"
- "lib/firebase_options.dart"
- "scripts/**/dart/**/firebase_options.dart"
linter:
rules:
prefer_relative_imports: true
prefer_single_quotes: true
require_trailing_commas: true
no_default_cases: true
use_colored_box: true
Linterパッケージ候補
-
flutter_lints：Flutter公式で使われているLintルールをまとめたパッケージ。Flutterバージョン2.5以降新規作成したFlutterプロジェクトに標準搭載されている pub.dev -
pedantic_mono：monoさんが作成したLintrルールパッケージ。flutter_lintsをベースにより厳しめにルールを設定したもの pub.dev -
very_good_analysis：Flutter開発で有名な米国のVeryGoodVenturesで利用されているLintルールパッケージ pub.dev -
lint：海外の厳しめのルール設定のLintルールパッケージ。 pub.dev
Linterの導入
- dev_dependenciesに追加
- analysis_options.yamlにinclude
静的解析の実行
flutter analyzeコマンドで実行することが出来ます。CI/CDで静的解析を行う際もワークフロー内でflutter analyzeコマンドを実行します。
静的解析の修正
静的解析を行った結果、エラーとなったコードをdart fix --applyコマンドで修正可能なコードを自動修正する事もできます。修正前にどのような修正が行われるのかを確認したい場合は、dart fix --dry-runで確認することが出来ます。
CI/CDの静的解析の結果を通知する
CI/CDで実行された静的解析の結果をPRに通知することがよく行われます。その際に用いられるのが Danger というツールです。
導入には以下のようなステップが必要になります。
- Gemfileを作成
- Dangerfileを作成
- CIワークフロー内で実行
Flutter用のDangerとしてrubyで書かれたdanger-flutter_lintというライブラリが存在します。こちらを使って実現します。
1. Gemfileを作成
プロジェクトのルートに以下のGemfileを追加
# frozen_string_literal: true
source "https://rubygems.org"
gem 'danger'
gem 'danger-flutter_lint'
2. Dangerfileを作成
DangerfileとはDangerの設定ファイルです。プロジェクトに応じて設定を変えたい場合のみ追加すれば大丈夫です。
// danger
// danger-flutter_lint
flutter_lint.only_modified_files = true
flutter_lint.report_path = "flutter_analyze_report.txt"
flutter_lint.lint(inline_mode: true)
Dangerfileはrubyに対応したファイルの為、独自の設定を追加したい場合はrubyで記述する必要があります。例えば、PRのタイトルにWIPが含まれている場合に警告を出したいとすると以下のように記述します。
// danger
warn("タイトルにWIPが含まれています") if github.pr_title.include? "[WIP]"
3. CIのワークフローを作成
最後にCIのワークフローに組み込みます。ここではGithub Actionsを用いた例を紹介します。(Github Actionsの使い方については割愛します。)。静的解析に関係のある部分だけを抜き出しています。flutter analyzeを使うので、こちらの記述の前にFlutterをインストールするのを忘れずに。
# Danger実行用にインストール
- name: Install Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: 2.7
bundler-cache: true
# info、warning発見時、action失敗と判定されない為に、--no-fatal-infos --no-fatal-warningsを付与
- name: Analyze linting
run: flutter analyze --no-fatal-infos --no-fatal-warnings > flutter_analyze_report.txt
- name: Comment analyze result
uses: MeilCli/danger-action@v5.0.2
with:
plugins_file: Gemfile
danger_file: Dangerfile
danger_id: danger-pr
env:
# github-botを使用する為、GITHUB_TOKENでコメントを投稿
DANGER_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
参考
heyhey1028[Flutter/Dart] Formatterの設定
FlutterおよびDartのコード整形のルールは公式が以下で定義しています。dart formatコマンドを使うことで自動的にこれらのルールをコードに適用し、整形することが可能です。
dart formatはIDEにプラグインを入れておくことで開発中に逐次整形することが出来ます。もし整形が漏れてしまってもロジックには影響を与えませんが、開発メンバー間の設定が異なる事で何度も整形部分がPRに入り込んでしまうことがあり、煩わしくなることがあります。自動で行われるようにしておくと、整形が統一され、そんな煩わしさからも解放されるので、お勧めです。
LEFTHOOK
参考