Bernd DittrichのUnsplashによる写真
ホラフォークス👋 , 私は、現代のAndroidアプリ配布の第2部に戻ります.最初の部分では、Githubのアクションと内部アプリケーションの共有を使用して内部ディストリビューションを自動化する方法を見ました.あなたが最初の部分を逃したら👇

Githubアクションパートによる現代のAndroidアプリ配布 - 私

サマルViradiya・ 月25日・ 6分読む

#android #github

この部分では、Githubのアクションとテストトラックを通じて、あなたの生産リリースを自動化する方法を参照してください.

自動化アプリケーションのリリースをテストトラック

最初の部分では、我々はすぐに開発ビルドを共有することができます内部アプリの配布を見た.BookMyShowで、我々はInternal App Sharingを通してQAのために我々の特徴レベルビルドを配布します.しかし、リリースでのライブに行く前に、統合ビルドの正式な内部起動についてはどうですか?テストトラックでは、それをテストし、貴重なフィードバックを得るために観客の限られたセットにビルドを配布することができます.再生コンソールは、ビルドを配布する3つのトラックを提供しています.
内部(100テスターに限る)

閉鎖(招待のみであるクローズドグループ)

オープン(誰でもテストプログラムに加わることができます)

したら、あなたの現在のトラックに応じて、オープン、オープン、または生産トラックにそれを促進することができますビルドに満足している.テストトラックhereの詳細を読む.
このプロセスを自動化する方法を見てみましょう.高いレベルで、我々はこれを見ています.
リリースビルドのためのトリガ
ワークフローを作りましょう.
あなたのワークフローをトリガするイベントを決定する必要があります.プリリリースディストリビューションについて話しているので、通常はリリースブランチからのものであり、ビルドをトリガーするイベントはより具体的でなければなりません.リリースをタグ付けすることは、リリースビルドを引き起こすイベントの1つでありえました.これを達成する方法を見ましょう.

name: Internal release
on:
  push:
    tags:
      - '[1-9]+.[0.9]+.[0.9]+'

ご覧のように、あなたのバージョン名スタイルのためにregexを指定する必要があります、そして、あなたがあなたのリリースをタグするたびに、それは我々のワークフローを引き起こします.

Note: Please make sure to bump the version name and version code before tagging your release.

ここでビルドジョブを設定する必要があります.

jobs:
  build:
    name: Building release app
    runs-on: ubuntu-latest
    steps:
      - name: Checking out tag
        uses: actions/checkout@v2
      - name: Settting up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Runing build command
        # Run your own gradle command to generate release build.
        run: ./gradlew bundleRelease
      - name: Uploading build
        uses: actions/upload-artifact@v2
        with:
          name: bundle
          path: app/build/outputs/bundle/release/app-release.aab

これは前の部分で見たものと非常に似ています.

Note: In case you are uploading apk you might need to upload mapping.txt as well which contains the obfuscated class, method, and field names mapped to the original names. This mapping file also contains information to map the line numbers back to the original source file line numbers. This file is required by Google Play to deobfuscate incoming stack traces from user-reported issues so you can review them in the Google Play Console.

最終的な仕事はテストトラックにビルドをアップロードすることです.それを達成する方法を見ましょう.
まず、前の仕事でアップロードしたビルドをダウンロードする必要があります.

Note: In case you uploaded apk file in the previous job you need to upload a mapping file as well and the same you need to download.

upload_to_test_track:
    name: Uploading build to Internal test track
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Downloading build
        uses: actions/download-artifact@v2
        with:
          name: bundle

ダウンロード後は、テストトラック上のビルドアップロードのためのGithubアクションを使用するだけの問題です.r0adkll/upload-google-play@v1アクションを使用できます.

      - name: Uploading to test track
        uses: r0adkll/upload-google-play@v1
        with:
          # Your service account JSON GitHub secret
          serviceAccountJsonPlainText: ${{ secrets.[your-github-service-acc-json-secret] }}
          # Your package name
          packageName: 'your-package-name'
          releaseFiles: app-release.aab
          track: internal

あなたが指定する必要がある重要なことは

あなたのサービスアカウントJSONファイルは、Github秘密を通してプレーンテキスト(またはJSONファイルとして)としてファイルします.

あなたのアプリケーションパッケージ名.

トラックをビルド(内部/生産/アルファ/ベータ)にアップロードします.

ファイルをマッピングする

アクションはまた、他のものの束を指定することができますが、上記のすべてが必須である重要なパラメータです.

Note: If you are uploading bundle you need to enroll in app signing by Google Play before uploading your app bundle on the Play Console. Read more about it here.

おめでとう!自動生成のためのワークフローだけでなく、生産リリースは準備ができて💪
フルワークフローの要点はこちら👇
< div >
これは、Githubアクションによる現代のAndroidアプリ配布の2部シリーズの終わりをもたらします.あなたが人々にあなたのビルドと配布プロセスを自動化することを学んでいることを望みます.いつもフィードバックが歓迎されているので、コメントしてください.p >
それは今の人々のためです.今度まで👋. ハッピーコーディング

Thanks to and for proofreading this.