네이티브 앱은 웹처럼 URL만 알면 누구나 접근할 수 있는 환경이 아니다. 안드로이드는 플레이스토어에 앱이 올라가지 않았을 때, 실제 단말기에서 사용을 해보려면 apk 파일 설치가 필요하다. (iOS는 테스트 플라이트라는 고유한 툴을 사용해서 사전에 앱을 써볼 수 있더라.)

 

가끔 여러 명과 함께하는 토이 프로젝트에서 안드로이드 개발을 하다 보면, 앱이 어떻게 만들어지고 있는지 궁금해하는 다른 분들에게 apk를 전달해야 할 일이 있다. 그때마다 안드로이드 스튜디오에서 빌드 -> zip으로 압축 -> 카카오톡으로 전달의 프로세스를 거치곤 했다. 어려운 일은 아니지만 변경사항이 생겼을 때마다 이렇게 파일을 주고받는 게 조금은 번거롭게 느껴졌다.

 

다른 서버 개발자 분들이 jenkins로 깃허브에 푸시만 하면 알아서 배포가 되게 자동화해둔 것을 보게 되었다. 정확히 어떤건지는 몰라도 굉장히 편리해 보였다. 비슷한 환경을 만들어 보려고 CI/CD 툴에 대해 찾아봤다. (잘 설명된 글)

 

CI 설정을 하려면 가장 먼저 원격에서 접속할 수 있는 CI 서버가 필요하다. 한두명에게 파일을 전해주려고 서버까지 마련을 해야 하나?라는 생각이 들었다. 그때 GitHub Action이라는 것을 처음으로 알게 되었다. GitHub 내에서 repository에 직접 CI/CD 설정을 걸어둘 수 있고, public access면 무료로 쓸 수 있기까지 하다. 게다가 android sdk, gradle 등의 설치도 필요가 없다.

 

튜토리얼을 보고 따라하니 사용법도 그렇게 어렵지 않았다.

그래도 나중에 다시 쓸 때 까먹을 것 같아서 적용 방법을 간단히 기록해두려고 한다.

 

시작하기

GitHub repo에서 Actions라는 탭을 클릭해보면 이렇게 workflow를 설정할 수 있는 페이지가 나온다.

workflow를 정의해놓으면 특정 이벤트가 발생할 때마다 빌드, 테스트, 배포 등 사용자가 정의해둔 동작이 실행된다.

 

이제 'New workflow' 버튼을 클릭하면 새로운 workflow를 만들 수 있다.

프로젝트 root 경로에 .github/workflow 디렉토리가 생기게 되고, 그 안에 .yml 파일을 만들어 상세한 설정을 할 수 있다.

 

스크립트가 크게 name, on, jobs으로 나뉜다는 것을 알 수 있다.

  • name : 말 그대로 CI 이름이라 자유롭게 작성하면 된다.
  • on : action이 어떤 순간에 발생하게 할 건지 이벤트의 종류(ex.pull, pull_request)와 브랜치(ex.master, develop)를 정의할 수 있다.
    • 단일 이벤트를 지정하고 싶다면 on: push
    • 여러 개의 이벤트를 지정하고 싶다면 on: [push, pull_request] 이런 식으로 쓰면 된다.

Event 예시) master, develop 브랜치에 push가 발생했을 때, develop 브랜치에 pull request가 발생했을 때 job을 실행시킨다.

on:
  push:
    branches:
      - master
      - develop
  pull_request:
    branches:
      - develop
  • jobs : 이벤트가 발생한 순간 실행할 step을 정의할 수 있다. step마다 실행할 shell commands를 정의할 수 있다. 자세한 문법은 여기에 나와있다.

Job 예시 1) 유닛 테스트 결과를 보고 싶다면

jobs:
  test:
    name : Run Unit Tests
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Unit tests
      run: bash ./gradlew test --stacktrace

Job 예시 2) 빌드 결과를 보고 싶다면

jobs:
  build:
      name: Build and Run
      runs-on: ubuntu-latest

      steps:
      - uses: actions/checkout@v1
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Build with Gradle
        run: ./gradlew build

 

Job 예시 3) apk를 추출하고 싶다면 (여기서 path는 실제 apk 생성 경로와 일치해야 동작한다는 점 참고)

jobs:
  apk:
      name: Generate APK
      runs-on: ubuntu-latest

      steps:
        - uses: actions/checkout@v1
        - name: set up JDK 1.8
          uses: actions/setup-java@v1
          with:
            java-version: 1.8
        - name: Build debug APK
          run: bash ./gradlew assembleDebug --stacktrace
        - name: Upload APK
          uses: actions/upload-artifact@v1
          with:
            name: app
            path: app/build/outputs/apk/debug

 

apk 파일을 생성하는 workflow 스크립트

name: Android CI

on:
  push:
    branches:
      - master
      - develop
  pull_request:
    branches:
      - develop

jobs:
  apk:
    name: Generate APK
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Build debug APK
        run: bash ./gradlew assembleDebug --stacktrace
      - name: Upload APK
        uses: actions/upload-artifact@v1
        with:
          name: app
          path: app/build/outputs/apk/debug

 

파일을 저장하고 나면 이제 알아서 돌아간다. Actions 탭에 들어가면 가장 최근 실행된 결과를 볼 수 있다.

클릭해보면 Artifacts 항목에서 apk 파일을 다운로드할 수 있다. (디버그 apk라서 용량은 좀 크다)

 

참고 - Pricing

  • 기본적으로 public access인 레포는 무료로 사용이 가능하다. github는 기업에겐 어떤지 몰라도 개인에게는 혜택을 퍼주는 혜자 기업인 것 같다..
  • private의 경우 계정 별로 무료로 사용할 수 있는 한도치가 정해져있고, 매달 초기화된다. 한도를 초과할 경우 넘어간 만큼 요금 지불을 해야한다. (참고)
  • 내가 github action을 사용 중인 레포에서 한번 CI가 돌아갈 때마다 4분 정도가 소요되는 것을 보니, 이벤트가 너무 자주 돌아가지 않게 설정해두면 토이 프로젝트 정도는 private에서도 무료로 사용할 수 있을 거 같다.

계정 권한 별 무료로 사용할 수 있는 한도치

 


마치며

이제 Github action이 설정된 레포 링크만 알려주면 아무 때나 가장 최근에 작업한 버전의 apk 파일을 다운로드할 수 있게 됐다.

나도 아직 깊게 써보진 않았지만 단점을 굳이 꼽아보자면 GitHub 로그인을 하지 않으면 이 Actions 탭에 접근할 수 없다는 건데, 개발 프로젝트에서 같이 협업하는 사이인데 GitHub 계정이 없는 사람은 거의 없으므로 나한테는 큰 문제가 되지 않았다.

 

 

참고 자료