FlutterプロジェクトでGithubActions for CI / CDの無料機能を使用する

GitHub Actionsは、リポジトリを使用して日常的なアクションを自動化し、プロジェクトのCI / CDを作成するのに役立つツールです。



GitHubユーザーは、サービスインフラストラクチャでGitHubアクションを実行するために月に2000分を取得します。この自由な時間を有効に活用しましょう。



Flutterアプリケーションの開発者向けに、GitHubアクションを使用してプルリクエストごとにテストとコードアナライザーを実行し、アーティファクトを作成してFirebaseでテストするためにデプロイする方法を説明します。







人はすぐに良いことに慣れます。そして、彼はそれにとても慣れているので、それがいつもこのようではなかったという事実についてさえ考えません。男と山羊についての古い逸話が言うように、人生のすべての喜びの実現は、あなたがこれらの非常に喜びを奪われたまさにその瞬間に起こります。



あなたの作業プロジェクトがCI / CDでうまくいっているなら、あなたは幸運な人です。

スタートアップで作業していて、すべてのパイプラインとフックを自分の手で慎重に構成しているかもしれません。



DevOpsチーム全体があなたの幸福を管理している可能性があります。毎月、新しい統合、目の前でのビルド時間の溶解、想像を絶するすべての場所にアセンブリを展開するための高度な技術で満足しています。



それは問題ではありません。重要なことは、アセンブリが実行可能であることを常に確信していると同時に、開発者を常にうつ病やうつ病に陥らせるという非常に退屈な日常業務を自分で免れることです。ちなみに、最後にJiraの問題のステータスを手動で変更したのはいつですか？コメントを書いていただければ幸いです。

あなたの快適ゾーンを離れる

彼らはどこで快適ゾーンを離れますか、そして最も重要なのは、なぜですか？多くの理由。友人から、自分のバー用の小さなアプリケーションの作成を手伝ってほしいと頼まれました。あなたはついに夢のペットプロジェクトを実装する時間を見つけたか、プロジェクトの一環として誤って作成されたライブラリをリリースすることにしました。最後に、あなたとあなたの同僚は、ワークショップ用の小さなサンプルプロジェクトを書くことにしました。



どのシナリオでも、新しい興味深いタスクからのインスピレーションは、「空気のない環境」でのソフトウェア開発の厳しい現実とすぐに衝突するでしょう（はい、ある時点で、空気のようなスマートコレクターが必要になります）。

「CI / CDは難しい…」

そんな時、普段は自分に何と言っていますか？「わかりません！フロントエンド/携帯電話を書いているところですが、あなたのジェンキンスについては何も知りません！」そのようなことを知る必要はないと言ったらどうしますか？



はい、コンソールコマンドを使用してプロジェクトをビルドできる必要があります-それだけです。たとえそれが個人的な小さなプロジェクトであり、IDEを消化するのがすでに難しい巨大なマルチモジュールモンスターでなくても、あなたはあなたの人生を大いに単純化することができます。



Github Actionsはとてもシンプルなので、おばあちゃんでも簡単にセットアップできます。

それでは、投稿は何についてですか？

すべてがとても単純な場合、なぜこの作品を読んで時間を無駄にするのですか？箇条書きでお答えします。

• Flutter. CI . , Flutter- . ,
  
  
• . Github Actions —  . 2 000 ( ). - , .
  
  
• . Flutter Android iOS , - . , , , .
  
  

c CI/CD , . . ($).

Github Actions, !

Github Actionsは、リポジトリのワークフローを自動化できるサービスです。コードを直接記述する以外に、プロジェクトで手動で行うことはすべて、Githubアクションに委任できます。一次情報源にすぐに精通したい場合は、公式ドキュメントにアクセスしてください。



多くの場合、何を自動化する必要があるのか​​まったくわかりません。チームには、サービスの複雑なAPIを理解してから、ソリューションを最初から作成してデバッグする時間がありません。マーケットプレイスはこの問題を解決します。多くの一般的なタスクを解決する約5000の既製のアクションが公開されています（たとえば、Telegramでのイベントに関する通知の送信、プロジェクトソースの技術的負債の分析、変更されたファイルに応じてPRにラベルを設定します）。悪いニュース：それらの多くはシェアウェアであり、かなり厳しい使用制限があります。

作業プロセス

Github Actionsのすべては、ワークフローを中心に展開しています。各ワークフローは、何をするか、いつ行うかという2つの質問に答えます。



何をすべきか。ここには無数のオプションがあります。既製のスクリプトまたは自分で行うスクリプトを使用して、ビルドをビルド、テスト、およびデプロイできます。ワークフロー構成の詳細



いつ実行するか。リポジトリで発生するイベントでワークフローをトリガーできます。プルリクエストの作成、コミットタグのプッシュ、またはプロジェクトへの新しいスターの追加。フックの完全なリスト



ワークフローをイベントではなく、特定の時間または特定の頻度で実行する必要がある場合は、POSIXcron構文を自由に使用できます。定期的なイベントの詳細



リポジトリでは、多くの異なるワークフローが同時に共存できます。各ワークフローは個別のYAMLファイルに記述されており、各ファイルはリポジトリのルートにある.github / workflowsディレクトリに保存する必要があります。ワークフロー構文の詳細

実行時環境

Github Actionsには、ワークフローを実行するための2つのオプションがあります。

• Github-hosted runners — , . Windows, Linux macOS. , Codemagic, ( ). , , ;
  
  
• Self-hosted runners — , . Github , .
  
  

私の記事では、最初のオプションに焦点を当てます。私たちは可能な限り単純な道をたどっていますよね？

Flutterの基本的なワークフローの設定

ワークフローの構成を開始する前に、2つのことに同意する必要があります。



まず、ワークフローの主な役割は、コードベースの内訳を複雑にすることです。ビルドされない、潜在的な問題が含まれる、またはテストに失敗するコードは、主流になるべきではありません。



第二に：私の構成にはあなたのプロジェクトに関係のない微妙な点があるかもしれません。説明しようと思います。ただし、この記事をガイドとして使用している場合は、慎重に借りてください。



最後に、ワークフローで何をすべきかを決定しましょう。正しい方向に進むための計画が必要です。

完成したアセンブリへのステップバイステップ

上記の計画は、独自のワークフローを設定する際のチェックリストとして使用できます。するべき：

1. ワークフローに意味のある名前を付けます。
2. ワークフローが開始されるイベントを示します。
3. 起動する構成をマシンで決定します。
4. ワークフローの構成手順を決定します。

• プロジェクトをチェックアウトし、
• Javaのインストール。
• Flutterのインストール（覚えているように、クリーンなインスタンスを自由に使用できるようになるたびに）、
• プロジェクトパッケージのダウンロード、
• 静的アナライザーを起動し、
• テストの実行、
• ビルドアセンブリ自体、
• テスターが入手できる場所にビルドをデプロイします。

今、私たちの仕事は具体的な形になっています。実装に移りましょう。

名前

明らかに、名前がその本質をできるだけ正確に反映するように、ワークフローに名前を付ける必要があります。名前（docs）は、ワークフローの実行時にアクションコンソールに最初に表示されるものです。ワークフローにそのように名前を付けた理由は、すぐにわかります。

name: Flutter PR

トリガーイベント

「on」 ブロック（docs）を使用すると、登録時にワークフローを開始する1つ以上のイベントを指定できます。さらに、一部のイベントは微調整できます。 



どのイベントを選択しますか？内訳を見逃さないように、少なくとも既存のすべてのイベントを指定できます。その後、アセンブリはほぼ継続的に実行されますが、これが必要ですか？いいえ、この場合のように、無料料金プランの制限は素晴らしくすぐに終了します。最適なソリューションを探します。



私たちのプロジェクトが、プルリクエストの作成を通じてのみ、コードをプロジェクトのメインブランチに直接プッシュすることはできないという合意に準拠していると仮定しましょう。ワークフローがプルリクエストの作成に応答し、変更されたコードベースからプロジェクトをビルドするかどうかは論理的です。

on: pull_request

$これは仕事には十分ですが、解決策はまだあまり最適ではありません。ビルドは、プルリクエストが作成されるたびにトリガーされます。プロジェクトのメインブランチに向けられたプルリクエストのみに関心があるため、これは冗長です。Github Actionsの構文を使用すると、関心のあるブランチの名前（またはマスク）を指定できます。

on:
 pull_request:
   branches:
     - "dev/sprint-**"

$そしてまた、プロセスを最適化する方法を探しています。理論上でも、プロジェクトに害を及ぼすことのないファイルがあります。プロジェクトドキュメント、Swagger、一般的なコードスタイルの設定、IDEです。幸い、パスマスクによってそのようなファイルを無視することができます。その結果、「on」ブロックは次のようになります。

on:
 pull_request:
   branches:
     - "dev/sprint-**"
   paths-ignore:
     - "docs/**"
     - "drz-swagger/**"
     - ".vscode/**"

重要：プルリクエストは、マージする準備ができている場合にのみ行ってください。作成済みのプルリクエストを次にプッシュするたびに、ワークフローが再開されます。

ジョブ構成

これで、ジョブを構成する準備が整いました（docs）。今こそ、ワークフローでジョブが果たす役割を明確にするときです。



すべてのワークフローには、少なくとも1つのジョブが含まれている必要があります。これは、ステップバイステップの説明を含むジョブであるステップ私たちは私たちのプロジェクトを実行します。1つのワークフローのジョブ数、および1つのジョブのステップ数に制限はありません。デフォルトでは、あるジョブの別の結果への依存関係が指定されていない限り、すべてのジョブが並行して実行されます。私たちのプロジェクトには、プロジェクトの構築を担当する単一の仕事があります。

環境のセットアップ

クリーンな仮想マシンインスタンスでワークフローが実行されるたび。選択できるのは、このマシンにインストールされるオペレーティングシステムだけです。何を選ぶ？



ターゲットプラットフォーム（AndroidとiOS）用のFlutterアプリケーションを構築することを計画しているため、macOSを選択するのは魅力的です。悪いニュース。 macOSでインスタンスを使用した場合の1分間は、Ubuntuでインスタンスを使用した場合の10（10 !!!）分として請求されます。 Windowsのインスタンスでは、この場合、iOSアセンブリをアセンブルすることはまだ不可能であり、その使用時間はUbuntuのインスタンスの2倍であるため、まったく意味がありません。$の請求についての詳細



2,000分の無料時間が200にならないようにするにはどうすればよいですか？良い解決策はありません。プルリクエストを作成するときに、iOSでビルドをビルドしないことにしました。これは、iOSビルドの安定性に影響を与える可能性があります。妥協オプションもあります-pubspec.yamlまたは/ iosディレクトリから任意のファイルを変更する場合にのみmacOSでiOSビルドをビルドするか、それ以外の場合は、Ubuntuを使用するインスタンスでAndroidビルドのみをビルドします。これは、「on」ブロックの無視ファイルを設定する方法と同様に行うことができます。

jobs:
 build:
   runs-on: ubuntu-latest

技術仕様と、インストールされている「すぐに使用できる」ソフトウェアのリストを 確認できます。残念ながら、FlutterとJavaはこのリストに含まれていません。ワークフローを実行するたびに手動でインストールする必要があります。



慌てて急いではいけません。既成のアクションが私たちの助けになり、それを私たちの仕事のステップで使用することができます。2つ使用します。

• アクション/セットアップ-java -Java環境をセットアップするための公式アクション。
  
  
• subosito / flutter-actionは、 FlutterSDKをダウンロードしてインストールするための非公式のアクションです。それ自体が十分に証明されています。たとえば、目的のフレームワークチャネルを指定したり、特定のSDKバージョンに切り替えたりするなど、必要なことをすべて実行できます。
  
  

steps:
      - uses: actions/setup-java@v1
        with:
          java-version: "12.x"

      - uses: subosito/flutter-action@v1
        with:
          channel: "stable"

リポジトリのクローニング

Githubから数分間レンタルしたマシンのクリーンなインスタンスがあります。前のステップでは、必要なすべてのソフトウェアをインストールしました。次に、プロジェクトのソースリポジトリのクローンを作成する必要があります。これを行うには、既製のツールを使用します。

• アクション/チェックアウトは、ほとんどの場合に必要とされない大量の設定を使用してリポジトリをクローン化するための公式アクションです。ワークフローはクローン作成しているリポジトリで直接実行されるため、明示的に指定する必要はありません。
  
  

- uses: actions/checkout@v1

依存関係の読み込み

これまで、私たちは自分たちの手で手順を実行するのではなく、私が提供する既成のアクションのみを使用していました。次に、プロジェクトのアクティブビルドフェーズの実装に移ります。それでは、ステップの実装を自分で作成するときが来ました。



ビルドする前に、pubspec.yamlファイルの依存関係ブロックにリストされているすべてのパッケージと、それらのすべての一時的な依存関係をダウンロードする必要があります。これを行うために、FlutterSDKはすぐに使用できる簡単なコマンドを提供しますflutter pub get。ステップの実装は、1つの端末コマンドを呼び出すことで構成できます。この場合、次のステップは、このコマンドの完了時にのみ呼び出されます。

- run: flutter pub get

プロジェクトの構造が複雑で、ローカルに接続されている多数のダーツパッケージが含まれている場合、問題が発生します。flutter pub getこれらの各パッケージを明示的に呼び出さずにプロジェクトを構築することは不可能です。私のプロジェクトでは、このようなパッケージはルートディレクトリにある/ coreフォルダーに収集されます。以下は、この問題を解決するスクリプトです。これは、同じルートディレクトリの/ scriptsフォルダーにあるflutter_pub_get.shファイルに記述されています。

flutter pub get
cd core
for dir in */ ; do

    echo ${dir}
    cd ${dir}
    pwd
    flutter pub get
    cd ..
    pwd
    if [ "$#" -gt 0 ]; then shift; fi
    # shift
done

stepの実装は任意の端末コマンドにすることができるため、シェルスクリプトの実行を妨げるものは何もありません。

- run: sh ./scripts/flutter_pub_get.sh

静的コード分析

Flutterは、組み込みコマンドを使用しflutter analyzeて静的アナライザーを実行するように勧めています。これは、コードベースの潜在的な問題を早い段階で特定するのに役立ちます。バグが本番環境に到達する前、またはコードが読み取り不能でサポートされていない混乱に変わる前です。



すぐに使用できる機能を利用することもできましたが、残念ながら、デフォルトのチーム動作flutter analyzeには欠陥があり、間違ったタイミングでワークフローが台無しになります。 



アナライザーによって検出された問題は、情報、警告、エラーの3つの重大度レベルに分類されます。この号では分析中に情報クラスの問題のみが見つかった場合でも（そして今ここでそれらを修正することに時間を費やす価値があるとは限らない）、コマンドはコード「1」を返し、その結果、アセンブリがクラッシュすることが説明されています。



一時的な解決策として、次のスクリプトを使用することをお勧めします。今後、エラーレベルに問題がある場合にのみ、アセンブリがクラッシュします。

OUTPUT="$(flutter analyze)"
echo "$OUTPUT"
echo
if grep -q "error •" echo "$OUTPUT"; then
    echo "flutter analyze found errors"
    exit 1
else
    echo "flutter analyze didn't find any errors"
    exit 0
fi

ワークフローの次のステップでシェルスクリプトを実行します。

- run: sh ./scripts/flutter_analyze.sh

テストの実行

プロジェクトにテストがある場合は、正しい方向に進んでいます。テストが機能するには、テストを作成するだけでは不十分です。実装の欠陥を時間内に修正したり、必要に応じて更新したりするために、テストを定期的に実行する必要があります。したがって、次のステップでは、実装します

- run: flutter test

注意：実装されたテストを含まない空のテストクラスは、ワークフロー全体をクラッシュさせます。唯一の方法があります。少なくとも1つのテストを実装する準備ができるまで、テストクラスを宣言しないでください。

構築して署名する

すべての準備作業は終了しました。コードに明らかな問題が含まれていない可能性が高いことを確認しました。次に、最も重要な段階であるアーティファクトの作成に移ります。つまり、APKを構築します。



アセンブリ自体の実装は非常に簡単です。ターミナルコマンドのフラッタービルドを自由に使用できます。これは非常に深く構成可能で、特定のフレーバー、メインファイル、ABIのアーティファクトをビルドできます。この記事ではこれらのニュアンスについては説明していません。必要に応じて、追加のコマンドフラグを使用してください。

- run: flutter build apk --release

私たちの目標は、リリースキーでアセンブリに署名することです。そして、この段階では、リリースキーストアとそのすべてのエイリアスとパスワードをどこかに保存する必要があるため、セキュリティの問題を解決する必要があります。



Githubを使用すると、文字列値を専用のシークレットリポジトリに安全に保存できます。ここで利用可能なデータは適切なリポジトリに保存され、ワー​​クフローの任意のステップからプログラムで読み取ることができます。同時に、値はGithubWebインターフェイスからは表示されません。削除または上書きのみが許可されます。







これは、特に独自のセキュリティサービスの場合、エイリアスとパスワードに適したソリューションのように見えますが、*。jksファイル自体はどうでしょうか。リポジトリがプライベートであっても、リポジトリにプッシュするのは良い考えではないようです。残念ながら、Githubはファイルを保存する安全な方法を提供していないため、回避する必要があります。



キーストアファイルを文字列として表すと便利です。そしてそれは本物です-あなたはそれをbase64でエンコードする必要があります。これを行うには、* .jksファイルを含むディレクトリでターミナルを開き、次のコマンドを実行します。次に、キーストアのbase64表現をコピーできるテキストファイルが作成され、Githubシークレットに保存されます。

openssl base64 < key_store_filename.jks | tr -d '\n' | tee keystore.jks.base64.txt

アセンブリに正常に署名するために必要なすべての要素が揃ったので、ステップの構成に進みます。 envブロックでは、その特定のステップのすべての環境変数を宣言します。シークレットからこれらの変数の値を取得します。

- run: flutter build apk --release
        env:
          STORE_PASSWORD: ${{ secrets.STORE_PASSWORD }}
          KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
          KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
          STORE_FILE: ${{ secrets.STORE_FILE }}

Androidホストでは、署名されたアセンブリをローカルで構築する機能を失うことなく、CIでも* .apkファイルに署名できるようにアセンブリ構成を記述する必要があります。keystoreConfig.gradleファイルがこの瞬間を担当します。keystore_release.propertiesファイルが見つかった



場合、ビルドはローカルで行われることがわかっています。つまり、ファイルから読み取るだけで、keystoreConfigのすべてのプロパティを初期化できます。それ以外の場合、アセンブリはCIで行われます。つまり、機密データの唯一のソースはGithubシークレットです。

ext {
   def releaseKeystorePropsFile = rootProject.file("keystore/keystore_release.properties")
   if (releaseKeystorePropsFile.exists()) {
       println "Start extract release keystore config from keystore_release.properties"
       def keystoreProps = new Properties()
       keystoreProps.load(new FileInputStream(releaseKeystorePropsFile))
       keystoreConfig = [
               storePassword: keystoreProps['storePassword'],
               keyPassword  : keystoreProps['keyPassword'],
               keyAlias     : keystoreProps['keyAlias'],
               storeFile    : keystoreProps['storeFile']
       ]
   } else {
       println "Start extract release keystore config from global vars"
       keystoreConfig = [
               storePassword: "$System.env.STORE_PASSWORD",
               keyPassword  : "$System.env.KEY_PASSWORD",
               keyAlias     : "$System.env.KEY_ALIAS",
               storeFile    : "$System.env.STORE_FILE"
       ]
   }
   println "Extracted keystore config: $keystoreConfig"
}

そして、これはkeystore_release.propertiesファイルがどのように見えるかです：

storePassword={___}
keyPassword={___}
keyAlias={___}
storeFile=../keystore/keystore.jks

Androidホストのbuild.gradleファイル の最後のステップは、keystoreConfigファイルをリリースビルド署名構成に適用することです。

android {
   signingConfigs {
       release {
           apply from: '../keystore/keystoreConfig.gradle'

           keyAlias keystoreConfig.keyAlias
           keyPassword keystoreConfig.keyPassword
           storeFile file(keystoreConfig.storeFile)
           storePassword keystoreConfig.storePassword
       }
   }
}

署名されたアセンブリはすでに私たちの手にあります！しかし、テストのためにそれを同僚にどのように拡張しますか？

荷降ろし

Github Actionsを使用すると、アセンブリを配布するためのほぼすべての既知のツールへのアーティファクトのアップロードを構成できますが、検討するオプションは2つだけです。

• Githubストレージ-アセンブリを独自のGithubストレージにアップロードする最も簡単な方法。箱から出してすぐに機能しますが、いくつかの制限があります。
  
  
• Firebase App Distributionは、BetaをCrashlyticsに置き換えたFirebaseエコシステムのサービスです。統合の構成は少し難しいですが、サービス自体の方がはるかに便利です。
  
  

Github Storage

Github Storageは、公式アクションを通じて簡単に統合できます。同僚がWebインターフェイスに表示するアセンブリの名前と、CIでアセンブルされた* .apkファイルへのパスを指定する必要があります。

- uses: actions/upload-artifact@v1
        with:
          name: APK for QA
          path: build/app/outputs/apk/dev/debug/apk_name.apk

主な問題は、限られたストレージスペースです。無料プランでは、500MBしか提供されません。最も奇妙なことは、Webインターフェイスを介してストレージ全体を一度に手動でクリアする方法が見つからなかったため、苔むしたアーティファクトからストレージをクリアすることだけを担当する別のワークフローを作成することで状況から抜け出しました。



ワークフローは毎日午前1時に実行され、1週間より古いすべてのアーティファクトを削除します。

name: Github Storage clear

on:
  schedule:
    - cron: '0 1 * * *'

jobs:
  remove-old-artifacts:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Remove old artifacts
        uses: c-hive/gha-remove-artifacts@v1
        with:
          age: '1 week'

Firebase App Distribution

Firebase App Distributionについては、既製のアクションwzieba / Firebase-Distribution-Github-Actionを使用して統合しました。 

- name: Upload artifact to Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
          appId: ${{ secrets.FIREBASE_ANDROID_PROD_APP_ID }}
          token: ${{ secrets.FIREBASE_TOKEN }}
          groups: testers
          file: build/app/outputs/apk/dev/debug/apk_name.apk
          debug: true

アクションが正しく機能するには、次のパラメータを渡す必要があります。

• appId -Firebaseプロジェクトの設定にあるアプリケーション識別子。
  
  
  
  
  
  
  
  
• トークン-サービスにアセンブリをロードするために必要とされるあなたのFIrebaseプロジェクトへの認証用トークン。トークンはFirebaseCLIを介してのみ取得できます。詳細については、公式ドキュメントを参照してください。
  
  
• file -CI上のコンパイル済み* .apkファイルへのパス。
  
  
• groups-このパラメーターはオプションですが、アップロードされたアセンブリが自動的に共有されるテスターグループのエイリアスを指定できます。
  
  

打ち上げと観察

最も単純なワークフローの準備が整いました。あとは、トリガーイベントを発生させて、ワークフローの進行状況を監視するだけです。

アドバイスと別れの言葉

これで、サイズ、開発強度、またはウォレットに関係なく、Flutterプロジェクトで単純なCI / CDメカニズムのすべての利点を享受できます。



最後に、このワークフローの作業中に思いついたヒントと所見を次に示します。

• workflow . workflow , , . - . , - workflow , .
  
  
• step’ shell-. workflow . . .
  
  
• Run Duration workflow. workflow , . workflow , step’. . Flutter SDK . — 5-6 .
  
  

まだまだたくさんの潜在的な改善と改善があります。ワークフローを改善するためのアイデアをコメントに書き込んでください。個人的に何が欠けていますか？おそらく、読者の最も興味深いアイデアの実装は、このトピックに関する次の記事の基礎を形成するでしょう。



すべてのスクリプトとワークフローは、テストアプリケーションのリポジトリにあります。



清聴ありがとうございました。



PS私たちのSurfチームは、Flutterに役立つ多くのライブラリをリリースしています。それらをSurfGearリポジトリにアップロードします。