사진은 Bernd Dittrich 에서 Unsplash
얘들아, 얘들아.👋우선, 나는 모두가 평안하기를 바란다.이제 구축/배포 주기에 대한 몇 가지 질문을 드리겠습니다.

테스트를 위해 수동으로 구축을 만드시겠습니까?

아직도 이메일/G-drive를 통해 응용 프로그램을 나눠주고 있습니까?

구축 및 배포 프로세스를 자동화하시겠습니까?

이러한 질문에 대한 대답이 긍정적이라면, 현재 하고 있는 일을 멈추고 구축/분배 주기를 자동화해야 합니다.
현대 안드로이드 버전과 GitHub 조작에 관한 두 부분으로 구성된 시리즈입니다.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는 게임 컨트롤러의 우수한 도구로 QA와 다른 이해관계자와 내부에서 aab/apk를 공유할 수 있습니다.BookMyShow 에서는 QA와 기능을 공유하여 구축하고 통합합니다.전체 체험은playstore에서 프로그램을 설치하는 것처럼 좋으며, 단지 화이트 리스트의 전자메일에만 한정됩니다.더 많은 사이드 캐리어가 필요하지 않습니다. 만약 이것이 충분하지 않다면, 작업 흐름에 통합할 수도 있습니다. apk/aab를 내부 응용 프로그램 공유(IAS)에 업로드한 후에 여가 시간에 공유할 수도 있습니다.
고위층에서 볼 때, 우리는 이 점을 주목하고 있다
구축 --> aab/apk를 IAS--> 공유 링크에 업로드합니다. 이전부터 시작합니다.
우리의 업무 흐름을 구축합시다.
워크플로우를 트리거할 이벤트를 결정해야 합니다.특정 지점에 대한 푸시 이벤트 또는 some other event 일 수 있습니다.대부분의 경우 공유 내부에서 QA로 구축된 지점의 푸시 이벤트입니다.우선 그것을 설정합시다.

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

보시다시피 구축 작업은 네 가지 임무가 있습니다.우리가 지정한 바와 같이, 이 작업은 Linux 기계의 실례에서 실행된다.새 기계에 지점을 서명하는 것처럼, 여기에서 같은 방식으로 항목을 설정할 때, 구축하고자 하는 곳에서 지점을 서명해야 한다.첫 번째 단계는 사용자 정의 작업actions/checkout@v2을 사용하여 완료합니다.다음은 프로젝트를 컴파일하기 위해 JDK를 설정해야 합니다.두 번째 단계는 사용자 정의 작업actions/setup-java@v1을 사용하여 완료합니다.
현재 우리의 가상 Linux 실례는 모든 설정을 준비했다.Gradle 명령을 실행하여bundle를 만들 때입니다. (bundle를 사용하지 않으면apk를 만들 수도 있습니다.)다음 단계는 이렇게 하고 묶음 파일을 만드는 것이다.마지막으로, 다음 작업에서 잠시 후에 접근할 수 있도록 생성된 패키지를 업로드합니다. 나중에 인용할 수 있도록 "bundle"이라는 부품의 이름을 입력하십시오.이 밖에 업로드할 패키지의 파일 경로도 언급했다.만약 당신이 작업을 뛰어넘어 파일을 공유하고 싶다면, 이것이 바로 당신이 실현할 수 있는 방식이다.사용자 지정 작업actions/upload-artifact@v2을 사용합니다.
좋습니다. 우리는 이미 절반의 작업 절차를 완성했습니다. 지금까지 우리는 다음 작업에서 그것을 사용할 수 있도록 공작물에 우리의 가방을 구축하고 저장하는 데 성공했습니다.
다음 일을 계속합시다. 하지만 그 전에...

나는 KitKat가 나에게 돈을 지불하지 않았다고 보증한다🤞
준비했어그럼 우리 계속합시다! 
마지막 작업이 상당히 복잡하기 때문에, 우리는 점차 분해할 것이다.
각 작업은 Linux 기기의 다양한 인스턴스에서 실행됩니다.우리가 이전에 작업을 설정한 방식과 같이 이 작업도 Linux 실례에서 실행된다.
아래 세 번째 줄의 특수한'요요'라벨을 주의하십시오.이 작업은 지정된 이름에 의존한다는 것을 GitHub에 알려줍니다.우리의 예에서, 그것은 구축 작업이다.
우리의 최종 업무는 세 가지 절차가 있다.우선, 우리는 이전 작업의 마지막 단계에 저장된 구축을 다운로드합니다.우리는'bundle'라는 이름을 통해 그것을 다운로드하려고 하는 공작물을 가리킨다.

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 작업을 작성하여 구축을 내부 응용 프로그램에 업로드하여 공유할 수 있도록 합니다.자세한 내용👇

사가르 비라디아 / 내부 애플리케이션 공유 작업

GitHub에서 aab/apk를 Play 콘솔에 업로드하는 내부 애플리케이션 공유 작업

지금까지 우리가 본 다른 사용자 정의 작업과 같이, 우리는 그것을 사용하여 구축을 내부 응용 프로그램에 업로드하여 공유할 것이다.
이 작업은 구축을 IAS에 업로드하려면 세 가지가 필요합니다.

텍스트 형식의 서비스 계정 JSON(GitHub secret에서 설정하는 것이 좋습니다)

응용 프로그램 패키지 이름입니다.

및 구축 경로입니다.

이전 두 개의 경우 서비스 계정 JSON을 GitHub secret으로 교체해야 합니다.마지막 것은 사용자 정의 경로를 지정하지 않으면 다운로드된 작업이 루트 단계에 있기 때문에 파일 이름일 뿐입니다.다운로드할 때 사용자 정의 경로를 지정하면 여기에서 같은 경로를 사용해야 합니다.
동작 출력 3개

downloadUrl  - 업로드된 가공소재에 대한 다운로드 URL입니다.

certificateFingerprint  - 생성된 가공소재에 서명하는 인증서의 SHA256 지문입니다.

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] 는 앞의 출력이다.

제목(기본값은 "메시지").

사용자 이름 느슨(기본값 "rtBot") - 메일 발송자의 이름입니다.실제 사용자 이름은 필요하지 않습니다.

      - 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 }}

워라!내부 응용 프로그램을 통해 자동으로 생성되고 배포되는 워크플로가 준비되었습니다!
다음은 전체 작업 절차의 요점이다👇

다음 버전에서 우리는 당신의 생산 버전을 어떻게 자동화하는지 탐색할 것입니다.

제2부분 참조👋

안전 유지

Thanks for proofreading this.