GitHub Actions으로 Flutter CI/CD 구축하기 - workflow 설정 2

GiHub Actions으로 Flutter CI/CD 구축하기 - GitHub Secret 설정

GitHub Actions으로 Flutter CI/CD 구축하기 - workflow 설정 1

 

이전 두 편에서는 깃허브 액션에서 제공하는 가상환경에서 빌드할 때 필요한 파일들과 데이터들을 깃허브 시크릿에 등록하는 작업, 그리고 이를 활용해서 안드로이드, iOS 배포를 위해 각각 apk, ipa를 빌드하여 구글 드라이브와 AppStore Connect의 api를 통해 배포하는 워크플로우릴 작성해보았다. 

 

이제 마지막으로 자동 빌드 후 Flutter  프로젝트의 버전 및 빌드 번호 수정 또한 자동화하는 workflow를 작성하겠다.

 

본인 프로젝트의 버전(빌드 버전) 관리 전략에 대해 먼저 간단하게 설명하면,

배포 환경이 개발 환경 배포용 Develop, 내/외부 테스트용  Stage, 실제 출시용 Release 으로 구분되어 있고

이를 Flavor로 구분하여 배포한다.

작업 브랜치도 각각 develop/stage/release 브랜치가 있으며 이 브랜치에 풀리퀘스트를 날리고

이를 담당자가 수행할 경우 자동으로 빌드 및 배포가 되는 워크플로우를 작성했다.

 

하지만 문제는 어떠한 이유로 현재 delvelop, stage, release는 같은 bundle id 를 공유하고 있어 세 환경의 빌드 배포 시 버전 빌드 번호를 하나로 묶어서 해야 한다는 점이다. 

그러므로 셋 중 어떤 배포 환경으로 배포하더라도 다음 배포 시에는 반드시 버전 빌드 번호를 +1하여 배포해주어야 한다.

이를 위한 workflow를 작성하겠다.

 

 

브랜치 간 버전 업데이트 및 동기화 워크플로우

• CI/CD를 포함한 코드 수정 요청은 Pull Request로, 버전 동기화 워크플로우와 같이 CI/CD로 인한 코드 수정은 Push로 진행
• develop 브랜치에서 CI/CD 배포를 한 후 버전 업데이트 워크플로우로 인해 develop,stage,release 브랜치의 버전을 수정하여 push하더라도 CI/CD가 실행되지 않음

1, 버전 동기화 워크플로우 작성

1) PAT(personal access token) 발급

깃허브 액션 가상환경에서 다른 브랜치로 체크아웃하여 수정해 커밋푸쉬하려면 권한이 필요함

이를 위해 PAT 발급

2) GitHub Secret에 PAT 등록

2, .github/workflows 디렉토리에 yml 파일 생성 및 작성

1) 워크플로우 이름과 트리거 작성

name: version sync

on:
  pull_request:
    branches: [ "develop", "stage" ]

2) job 명명 및 실행 환경 설정

jobs:
  version_sync:
    runs-on: macos-latest

3) 체크아웃 및 PAT으로 권한 입력

    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          token: ${{ secrets.GONGSACOK_PERSONAL_ACCESS_TOKEN }}

4) commit & push 할 사용자 정보 입력

      - name: git config
        run: |
          git config --global user.name '6cessfuldev'
          git config --global user.email '6cessfuldev@gmail.com'

5) 현 브랜치의 pubspec.yaml의 version build 번호 추출하여 GITHUB_ENV 선언

      - name: Calculate new version
        run: |
          version=$(grep 'version:' pubspec.yaml | awk '{print $2}')
          echo "Current version: $version"
          IFS='+' read -r base_version build_number <<< "$version"
          build_number=$((build_number + 1))
          new_version="${base_version}+${build_number}"
          echo "New version: $new_version"
          echo "NEW_VERSION=$new_version" >> $GITHUB_ENV

6) develop, stage, release으로 체크아웃하여 버전 수정 및 커밋 푸쉬

      - name: Checkout main Branch
        uses: actions/checkout@v3
        with:
          ref: develop
          token: ${{ secrets.GONGSACOK_PERSONAL_ACCESS_TOKEN }}

      - name: pubspec 수정 및 커밋 푸쉬
        run: |
          sed -i '' "s/version: .*/version: $NEW_VERSION/" pubspec.yaml
          git add pubspec.yaml
          git commit -m "빌드 넘버 업데이트 to $NEW_VERSION"
          git push origin develop

			- name: Checkout stage Branch
        uses: actions/checkout@v3
        with:
          ref: stage
          token: ${{ secrets.GONGSACOK_PERSONAL_ACCESS_TOKEN }}
        
      - name: pubspec 수정 및 커밋 푸쉬
        run: |
          sed -i '' "s/version: .*/version: $NEW_VERSION/" pubspec.yaml
          git add pubspec.yaml
          git commit -m "빌드 넘버 업데이트 to $NEW_VERSION"
          git push origin stage

 

위와 같이 빌드 버전을 관리할 경우 배포할 때마다 커밋이 쌓이게 된다는 단점?으로 보면 볼 수 있는 단점이 있다. 

Amazon S3와 같이 외부에서 따로 관리할 수도 있겠다만 간단한 방법으로는 이렇게 각 브랜치별로 pubspec.yaml 파일을 수정하는 것이 가장 간단한 접근 같다. 

 

본인 프로젝트 환경에 맞게 수정해서 잘 활용되었으면 좋겠다.