写真でBernd Dittrich on Unsplash
ヘイフォークス👋まず第一に、皆さんが無事であることを願っています.そうしたら、あなたのビルド/ディストリビューションサイクルについて質問しましょう.

手動でテストのビルドを作成しますか?

あなたはまだ電子メール/G -ドライブを介してアプリケーションを配布していますか?

を構築し、配布のプロセスを自動化したいですか?

あなたがそれらの質問のいずれかにyesと答えた場合は、あなたが今やっていることを停止し、ビルド/配布サイクルを自動化する必要があります.
これは、Githubアクションで現代のAndroidディストリビューションの2部シリーズです.私はあなたがGithubアクションを介してアプリケーションの配布を自動化するのを助けるつもりです.それで始めましょう.

This blog assumes that you are well versed with GitHub Actions. If not then I highly recommend exploring it and come back.

この部分では、内部のアプリケーションの共有を介して内部アプリケーションの配布を自動化する方法を見ていきます.

内部アプリの共有を介して内部アプリケーションの配布を自動化

Internal App Sharing あなたが内部のAB/APKをあなたのQAと他のステークホルダーと共有することができるプレー・コンソールの優れたツールです.アットBookMyShow 私たちは共有機能を構築するためのそれを使用して、統合されたビルドをQA.全体の経験は、それがwhitestedメールに制限されている以外は、プレイストアからアプリをインストールするのと同じくらい良いです.これ以上のサイドローブを必要とし、十分に良いされていない場合は、あなたのワークフローには、内部のアプリケーションの共有(IAS)にAPK/AABをアップロードしたら、スラックでそれを共有するように統合することができます.
高いレベルで、我々はこれを見ています
SLACKの前のステップからの共有リンク.
ワークフローを作りましょう.
あなたのワークフローをトリガするイベントを決定する必要があります.それは特定の枝へのプッシュイベントであるかもしれません、あるいはsome other event . 大部分のケースでは、それはあなたが内部の構築をQAに共有しているところから枝へのPushイベントです.まず設定しましょう.

name: Build, Upload to IAS and share on slack.
on:
  push:
    branches:
      # Specify branch from where you are sharing build
      - [branch_name]

では、先に述べたビルドステップの設定方法を見てみましょう.

jobs:
  build:
    name: Building app
    runs-on: ubuntu-latest
    steps:
      - name: Checking out branch
        uses: actions/checkout@v2
          with:
            # Specify branch from where you are sharing build        
            ref: '[branch_name]'
      - 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 build.
        run: ./gradlew bundleRelease
      - name: Uploading build
        uses: actions/upload-artifact@v2
        with:
          name: bundle
          path: app/build/outputs/bundle/release/app-release.aab

ご覧のように、ビルドジョブには4つのタスクがあります.このジョブは、Linuxマシンのインスタンスで動作します.あなたが新しいマシンのブランチをチェックアウトする方法と同じように、ここで同じプロジェクトを設定するときにも、ビルドを作成したい場所からブランチをチェックアウトする必要があります.最初のステップでは、カスタムアクションを使用しますactions/checkout@v2 . 次に、プロジェクトをコンパイルできるようにJDKを設定する必要があります.番目のステップはカスタムアクションを使用しますactions/setup-java@v1 .
今、仮想Linuxインスタンスはすべてのセットアップで準備ができていますGradleコマンドを実行してバンドルを作成する時です(バンドルを使用していない場合にもAPKをビルドできます).次のステップでは、バンドルファイルを作成します.最後に、最後のステップは、私たちが次の仕事の後でそれにアクセスするように、我々の生成された束をアップロードします.また、我々はアップロードされる我々の束へのファイル経路に言及しました.ジョブを横切ってファイルを共有する場合は、どのようにそれを達成することができます.カスタムアクションactions/upload-artifact@v2 .
それで、我々は我々のワークフローを途中で通しています、そして、これまで、我々は我々が我々の次の仕事でそれを使うことができるように、我々の束を構築して、保管しなければなりませんでした.
次の仕事に移りましょう.

私は、Kitkatが私にこれを支払わないと約束します🤞
レディ?それでは、動きましょう!畝
最後の仕事は非常に複雑なので、我々は段階的にそれを中断します.
各ジョブはLinuxマシンの異なるインスタンスで動作します.私たちの前の仕事をどのように設定したか、この仕事もLinuxのインスタンスで実行されます.
下記の行番号3に特別な'ニーズ'タグを通知します.このジョブが指定した名前に依存していることをgithubに伝えます.私たちの場合は、ビルドジョブです.
最後の仕事は3歩.まず、前のジョブの最後のステップに格納したビルドをダウンロードします.我々は、我々が'束'を与えた名前をダウンロードしたいアーティファクトを参照しています.

upload_to_internal_app_sharing:
    name: Uploading build to IAS
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Downloading build
        uses: actions/download-artifact@v2
        with:
          name: bundle

一度我々は内部のアプリケーションの共有にアップロードする時間がバンドルを持っている.また、それは恥知らずなプラグのための時間です🙈
BookMyShowと私の仲間のエンジニアは、内部のアプリケーションの共有にビルドをアップロードすることができますカスタムgithubアクションを書いた.それについて詳しく調べる👇

サマルViradiya / 内部アプリ共有アクション

アクションコンソールで内部のアプリケーション共有にAab / APKをアップロードするGithubアクション

我々が今まで見てきた他のカスタムアクションと同様に、我々は内部のアプリケーションの共有にビルドをアップロードするためにこれを使用されます.
このアクションは、IASにビルドをアップロードする3つのことが必要です.

あなたのサービスアカウントJSONのテキスト形式(私たちはあなたのgithubの秘密に設定することをお勧め)

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

そして、あなたのビルドへのパス.

それらの最初の2つについては、あなたのサービスアカウントJSONをGithub秘密に置き換える必要があります.最後に、カスタムパスを指定しない限り、ダウンロードしたアーティファクトがルートレベルになってから単純にファイル名になります.ダウンロード中にカスタムパスを指定する場合は、ここで同じパスを使用してください.
アクションは3出力を吐き出します

downloadUrl  - アップロードされたアーティファクトのダウンロードURL.

certificateFingerprint  - 証明書のSHA 256指紋は、生成されたアーティファクトに署名するために使用されます.

sha256  - アーティファクトのSHA - 256ハッシュ

ここでは、内部アプリケーションの共有にアップロードするためのステップです.

      - name: Uplaoding to IAS
        id: ias
        uses: sagar-viradiya/[email protected]
        with:
          # Your service account JSON GitHub secret
          serviceAccountJsonPlainText: ${{ secrets.[your-github-service-acc-json-secret] }}
          # Your package name 
          packageName: '[your-package-name]'
          aabFilePath: 'app-release.aab'

次のステップでは、通知しますdownloadUrl スラックの上のステップからの出力.また、カスタムアクションを使用してrtCamp/[email protected] . 次のように述べます.

あなたのスラックwebhook.

あなたが通知したいチャンネル.

メッセージ - 我々の場合downloadUrl 前のステップからの出力.

title (デフォルトは' message ').

スラックユーザ名 - メッセージの送信元の名前.“本物の”ユーザー名をする必要はありません.

      - name: Sharing on slack
        uses: rtCamp/[email protected]
        env:
          # Your slack webhook GitHub secret
          SLACK_WEBHOOK: ${{ secrets.[your-slack-webhook] }}
          # Slack channel where you want to notify
          SLACK_CHANNEL: [your-channel]
          SLACK_USERNAME: "JARVIS"
          SLACK_TITLE: "Internal testing build"
          SLACK_MESSAGE: ${{ steps.ias.outputs.downloadUrl }}

ウラ!内部のアプリケーションの共有を介してビルドと配布を自動化するためのワークフローは準備ができています!
フルワークフローの要点はこちら👇
< div >
次の1つでは、あなたのプロダクションリリースを自動化する方法を模索します.p >
パート2で会いましょう👋

スティセーフ!p >

Thanks for proofreading this.