계속하다

이 시리즈의 첫 번째 부분에서 저는 엑스포와 GitHub 동작을 결합하여 사용하는 선결 조건을 소개하고 첫 번째 동작을 설정하는 방법을 보여 주었습니다.테스트를 실행하고 지점을 발표하는 방법에 대한 더 많은 정보를 알고 싶으면 보십시오!
이 절에서, 나는 버전 제어의 목적과 Expoturtle 서비스를 이용하여 응용 프로그램을 구축하여 응용 프로그램을 나누어 주는 방법을 설명할 것이다.

버전 제어의 중요성

왜 저희가 버전을 원합니까?필요하십니까?이것은 어떻게 사용자 체험을 개선합니까?프로젝트가 증가함에 따라 의존항의 수량도 증가하고 더욱 관리하기 어려워진다.결국 다른 서비스와의 계약을 깨뜨리지 않고 업그레이드하는 것은 어렵다는 것을 알게 될 것이다.버전 제어는 간단한 방법으로 우리는 통용되는 규칙을 사용하여 이러한 의존항을 관리할 수 있으며, 이렇게 하면 모든 사람이 같은 페이지에 있을 수 있다.이것은 Semantic Versioning이며 형식Major.Minor.Patch의 주어진 규칙을 따른다.주요 변경 사항으로는 API 변경 중단, 보조 변경 후 호환 기능 추가, 패치 추가 오류 수정 등이 있습니다.
버전 제어를 정확하게 사용하면 응용 프로그램에 일련의 장점을 가져다 줄 수 있다.프로그램 내 버전 제어는 코드 라이브러리와 프로그램 버전을 검증하여 보고된 오류를 쉽게 디버깅할 수 있습니다.보조 업데이트 및 패치 업데이트만 전송되도록 공중 전송 업데이트(OTA)를 구성하여 애플리케이션 변경이 중단되지 않도록 합니다.또한 응용 프로그램의 다양한 주요 버전을 기존 버전과 비교하고 각 응용 프로그램 상점에서 최신 버전을 가져오지 않은 사용자를 위해 유지보수할 수 있습니다.
GitHub 게시 태그를 사용하여 워크플로우를 트리거하고 일치하는 태그의 이름 prod-Major.Minor.Patch 을 지정하여 응용 프로그램을 어느 게시 채널에 배치할지 알립니다.
코드에 많은 것이 있다.나는 먼저 코드를 제공한 후에 내가 한 몇 가지 선택을 상세하게 설명할 것이다.

name: Create Release
on:
  push:
    tags:
      - "prod-[1-9]+.[0-9]+.[0-9]+" # Push events to matching prod-*, i.e.prod-20.15.10

jobs:
  deploy_prod:
    name: Deploy To Production
    needs: test
    runs-on: ubuntu-latest
    outputs:
      releaseChannel: ${{ steps.releaseChannel.outputs.releaseChannel }}
      latestBinaryVersion: ${{ steps.latestBinaryVersion.outputs.version }}
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.head_ref }}
      - name: Fetch Tags
        run: |
          git fetch --prune --unshallow --tags -f
      - uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - uses: expo/expo-github-action@v5
        with:
          expo-packager: npm
          expo-username: ${{ secrets.EXPO_CLI_USERNAME }}
          expo-password: ${{ secrets.EXPO_CLI_PASSWORD }}
          expo-cache: true
      - uses: rlespinasse/[email protected]
      - name: Generate Release Channel # Release Channels are named prod-<Major Release>, i.e. prod-1, prod-3
        id: releaseChannel
        run: |
          RELEASE_CHANNEL=$(echo ${{ env.GITHUB_REF_SLUG }} | sed -r 's/\.[0-9]+\.[0-9]+$//')
          echo "::set-output name=releaseChannel::$RELEASE_CHANNEL"
      - name: Install Packages
        run: npm install
      - name: Get Latest Binary Version # Binary Version will be x.x.x based on the latest tag
        id: latestBinaryVersion
        run: |
          # Release tag finds the lastest tag in the tree branch - i.e. prod-x.x.x
          RELEASE_TAG=$(echo $(git describe --tags --abbrev=0))
          # Using param substitution, we output x.x.x instead
          echo "::set-output name=version::${RELEASE_TAG#*-}"
      - name: Echo Version Details
        run: |
          echo Build number is $GITHUB_RUN_NUMBER
          echo Latest release is ${{ steps.latestBinaryVersion.outputs.version }}
      - name: Expo Publish Channel
        run: expo publish --non-interactive --release-channel=${{ steps.releaseChannel.outputs.releaseChannel }}

이 작업은 이전 행에서 prod-x.x.x 이라는 태그를 누른 경우에만 수행됩니다.이를 통해 git 명령행 도구나 GitHub GUI를 사용하여 게시 페이지를 만들어 작업을 실행할 수 있습니다.
다음은 절차Fetch Tag와Get Latest Binary Version를 자세히 볼 수 있다.통상적으로, 만약 우리가 단지 환매에서 최신 라벨을 얻게 된다면, 최신 발행 라벨은 얻게 될 것이다. 따라서, 나는 우리가 인용한 지점에서만 최신 라벨을 얻는 것을 통해 이러한 고장 방지를 실현하기로 결정했다.
또한 응용 프로그램을 구축하기 위해 buildNumber 을 제공해야 합니다.이 경우 GitHub 작업 실행 번호 (repo의'작업'옵션 카드에 있는 매번 실행 이름 옆에 있는 작은 숫자입니다. 작업의 유일한 재생 시간을 계산하는 데 사용됩니다. 재생을 포함하지 않고 더 많은 정보를 찾을 수 있습니다 here.
app.json의 경우 Create Release또한 Expo의 게시 채널을 변경하여 이를 buildNumber 로 표시하고 최신 레이블에서만 주요 버전을 가져옵니다. OTA 업데이트를 이 채널로 보내기를 원하기 때문입니다.이것은 또한 다른 지점에서 버전을 만들어서 응용 프로그램의 이전 버전을 열 복구할 수 있도록 합니다. 그러면 어떤 것도 파괴되지 않습니다.

제작 및 게시

버전 간의 변화를 볼 수 있는 것은 게임 규칙의 변화자이다.그러나 다른 게시된 변경 로그를 만드는 것은 중요한 변경을 놓치는 압력을 준다.걱정하지 마세요. 지역사회에서 이미 많은 조작을 작성했습니다. 우리는 이러한 조작을 이용하여 과거의 제출에서 변경 로그를 생성하는 데 도움을 줄 수 있습니다. 그러면 어떤 변경도 빠뜨리지 않고 업무에 직접 집적할 수 있습니다.나의 예에서 나는 metcalfc/changelog-generator을 선택했다. 왜냐하면 그것은 매우 간단해서 임무를 완성할 수 있기 때문이다.완료되면 다른 커뮤니티 작업ncipollo/release-action을 사용하여 기존 게시 레이블을 만들거나 업데이트합니다.
예제 작업은 다음과 같습니다.

create_release:
    name: Create Release
    needs: deploy_prod
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: rlespinasse/[email protected]
      - name: Generate Changelog
        id: changelog
        uses: metcalfc/[email protected]
        with:
          myToken: ${{ secrets.GITHUB_TOKEN }}
          base-ref: 'prod-0'
      - name: Creating Release
        uses: ncipollo/release-action@v1
        with:
          body: |
            Changes in this Release: 
            ${{ steps.changelog.outputs.changelog }}
          token: ${{ secrets.GITHUB_TOKEN }}
          name: Release ${{ env.GITHUB_REF_SLUG }}
          allowUpdates: true

건축과 배전

마지막으로 가장 중요한 단계는 응용 프로그램을 구축하여 대중에게 배포하는 것이다.응용 프로그램의 구축 시간은 통상적으로 엑스포 구축 서비스number of projects queuing에 달려 있으며, 이 과정은 통상적으로 상당히 길다(20분에서 30분).매번 발표되기 전에 안드로이드와 iOS 바이너리 파일을 구축하기 위해 한 시간 정도 기다리는 것은 고통스러울 것이라고 상상해 보세요.하지만 고맙습니다. 우리는 모든 버전에서 자동으로 동작을 작성하고 바이너리 파일을 버전 자체, 심지어 각 응용 상점에 업로드할 수 있습니다!무료 Expo 구축 서비스를 사용할 때 일반적으로 URL이나 생성된 바이너리 파일을 가져오기 전에 서비스가 끝날 때까지 기다리거나 구축 작업이 끝날 때 갈고리를 사용하여 서버에 POST 요청을 보내는 두 가지 방법이 있다.간단하게 GitHub 작업에서 갈고리를 감청하지 않으려면 이전 옵션을 사용하기로 했습니다.
다음은 코드 세션입니다. android apk 패키지의 작업이 어떤 모습일지 설명합니다. iOS는 실행 중인 거울일 뿐입니다3.

 build_android:
    needs: [deploy_prod, create_release]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: rlespinasse/[email protected]
      - uses: expo/expo-github-action@v5
        with:
          expo-packager: npm
          expo-username: ${{ secrets.EXPO_CLI_USERNAME }}
          expo-password: ${{ secrets.EXPO_CLI_PASSWORD }}
          expo-cache: true
      - name: Install Packages
        run: npm install
      - name: Build Android Release
        env:
          APP_BUILD_VERSION: ${{ github.run_number }}
          APP_BINARY_VERSION: ${{ needs.deploy_prod.outputs.latestBinaryVersion }}
        run: |
          expo build:android --release-channel=${{ needs.deploy_prod.outputs.releaseChannel }} > buildLogAndroid.txt
          cat buildLogAndroid.txt
      - name: Parse Asset URL
        id: androidUrl
        run: |
          ASSET_URL=$(cat buildLogAndroid.txt | tail | egrep -o 'https?://expo\.io/artifacts/[^ ]+')
          echo The android url is $ASSET_URL
          echo "::set-output name=assetUrl::$ASSET_URL"
      - name: Download APK Asset
        run: wget -O example-${{ env.GITHUB_REF_SLUG }}.apk ${{ steps.androidUrl.outputs.assetUrl }}
      - name: Upload Release Asset
        uses: svenstaro/upload-release-action@v2
        with:
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          file: ./example-${{ env.GITHUB_REF_SLUG }}.apk
          asset_name: example-${{ env.GITHUB_REF_SLUG }}.apk
          tag: ${{ github.ref }}

내가 직면한 도전은 구축이 끝날 때 prod-Major 자산을 얻는 것이다.어떤 경우, 사용build:ios은 오류가 발생할 수 있습니다. 최신 버전만 업데이트되지 않기 때문에, 저는 신뢰할 수 있는 낡은 정규 표현식을 사용하여 이 문제를 해결하기로 결정했습니다.이후 자산이 발표되는 것은 순조롭다.
버전의 최종 출력은 이렇습니다!간결하고 우리가 필요로 하는 모든 부분을 포함한다.

개량하다

우리가 할 수 있는 몇 가지 개선은 GitHub Tag Bump 같은 지역사회 조작을 사용하여 최신 버전을 라벨로 저장하고 PR 설명에 따라 버전 라이브러리를 자동으로 업그레이드하는 것이다. 그러나 이것은 다음 이야기가 될 것이다.또 다른 개선이 필요한 점은 구축된 .apk 및 expo url:apk 바이너리 파일을 앱스토어에 자동으로 업로드하는 것이다.만약 당신이 이렇게 하고 싶다면, 이 과정에 대한 정보를 더 많이 읽을 수 있습니다 here.물론 개선해야 할 여러 가지 측면이 있습니다. 저는 CI/CD 작업 흐름에 기능을 추가하기 위해 재구매를 계속 연구할 것입니다.

결론

전반적으로 말하면 기획 작업 절차의 운행 방식과 실현 방식은 재미있는 과정이다.그 밖에 이 과정을 기록하는 것은 매우 재미있다. 이렇게 하면 다른 사람들이 GitHub에서 배우고 스스로 GitHub 조작을 사용할 수 있다.나는 나의 스승인 세바스티안에게 경의를 표하고 그가 이 과정에서 나에게 지도를 제공하고 다른 프로젝트를 위해 같은 업무와 업무 절차를 되돌아보는 것에 감사를 표하고 싶다.
너는 이곳에서 전체 환매를 볼 수 있다.포크로 그것을 찍어라, 네가 좋아하는 대로 놀아라.

회사 명 / github actions expo boiler 템플릿

엑스포와 GitHub의 협력

이것은 dev.to 게시물에서 설명한 예시이며, 더 많은 상세한 정보는 곧 제공될 것이다.
View on GitHub