담타 프로젝트 관리하기 3-2 - Codemagic 사용하기

담타 프로젝트 관리하기 3-1 - CI/CD 알아보기

담타 프로젝트 관리하기 3-1 - CI/CD 알아보기

이전 글에서 CI/CD에 대해 알아보고, 올인원 서비스를 우선 이용해봐야겠다고 마음을 먹었다.

Flutter앱의 CI/CD를 도와주는 올인원서비스는 Codemagic, Bitrise, Appcircle이 있다.

예전에 Netlify를 이용해 Gatsby 블로그를, Fleek을 이용해 IPFS에 올린 웹앱을 배포한 경험이 있기에 무료 사용량이라는 것이 개인 프로젝트에는 충분하고, 또 굉장히 만족스럽기 때문에 이번에도 충분할 것이라고 생각되었다.

또한 우선 빠르게 CI/CD 환경을 구축하는 것이 목표이기 때문에 github actions + fastlane 을 이용해서 구축하기보다는 이러한 서비스를 이용해서 구축하기로 했다.

그럼 이 세가지를 비교해보고 적당한 서비스를 선택해서 진행해 볼 예정이다.

비교

서비스	Codemagic	Bitrise	Appcircle
빌드 타임 / 월	500분	300분	20번
팀 가능 여부	불가능	불가능	불가능
최대 빌드 타임	120분	90분	30분

사실, 기능이 엄청 많은데 사용해보기 전에는 어떠한 기능이 필요한지 정확히 모르겠다.

내 앱의 빌드가 오래걸리진 않지만 그래도 빌드 타임이 넉넉한게 좋을 것이라고 생각되었고 Appcircle 월 20번의 빌드는 좀 짠 것 같아서 Codemagic, Bitrise 를 직접 이용해보고 선택하려 했으나,,,

 

생각보다 Codemagic의 설정이 오래걸리고 진행하다보니 Codemagic이면 충분할 것 같은데? 라는 생각이 많이 들었다.

Codemagic을 사용하다가 부족함이 있을 때 Bitrise를 이용하는 것도 좋고 Codemagic과 Bitrise는 결이 비슷하기 때문에 Bitrise를 알아볼 시간에 Github actions + fastlane 을 시도해보는게 좋다고 생각이 들었다.

 

그래서 Codemagic 을 이용해서 CI/CD를 구축해보도록 하겠다!

Codemagic

스포하자면, 이건 신세계다.

내가 진행했던 시간의 흐름 순으로 codemagic을 설정해보겠다.

 

설명이 조금 더 자세할 수 있는 글 - https://velog.io/@adbr/flutter-CICD-codemagic-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0

 

1. 회원가입 및 리포지토리 연결

나는 Github으로 가입했다.

Get started!

Github repository와 연결해준다.

Flutter App

Add application을 통해 앱을 추가해준다.

2. Build 환경 설정

어떤 플랫폼을 빌드할지, 어떤 컴퓨터로 빌드할지 설정해준다.

3. Build triggers

어떠한 상황일 때 Build 할지 정해준다.

이건 진짜 중요한 부분이라고 생각한다.

나는 PR을 받았을 때 하도록 했는데 나의 상황에 맞지 않았고 자세한 건 아래 쓰도록 하겠다.

4. Build

Flutter version, Xcode version, cocoaPods version을 선택해주면 된다.

자신이 로컬에서 쓰던 환경을 설정해주면 된다.

Android build format 같은 경우 나는 apk 파일 없이 appbundle을 만들어줬었기 때문에 선택했다.

Mode -> Release

평소에 빌드할 때 추가 argument를 이용했다면 Build arguments에 입력해주면 된다.

나는 원래 따로 없었다.

5. Distribution

Android code signing / ios code signing 은 키를 통해 나임을 증명하는 것,

Google Play, App Store Connect는 각각 플레이스토어, 앱스토어에 배포하는 설정이다.

우리가 갖고 있는 Keystore 파일을 올려준다.

keystore 비밀번호, key의 비밀번호를 입력한다.

Credentials을 발급하는 방법은 조금 복잡한데 아래를 참고하면 된다.

https://docs.codemagic.io/flutter-publishing/publishing-to-google-play/

Google Play publishing with Flutter workflow editor

Track은 내부테스트, 알파테스트, 베타테스트, 프로덕션이고 

Rollout fraction 은 몇 퍼센트의 사용자에게 배포할지, 안건드리면 100%

밑에 옵션은 읽어보고 선택

이 부분도 살짝 복잡하다. 아래 사이트 참고하면 된다.

https://docs.codemagic.io/flutter-code-signing/ios-code-signing/#step-1-creating-an-app-store-api-key-for-codemagic/

iOS code signing

나는 셀프 QA를 위해 TestFlight에 배포했다.

아마 Submit to App Store review를 체크하면 바로 심사를 요청할 것이다.

6. Notifications

빌드 성공 혹은 실패 내용이 이메일로 온다.

Slack과도 연동 예정이다.

빌드 해보기

첫 번째 도전

위에서 Build trigger를 PR의 경우로 설정해줬는데 아래그림의 Start new build를 누르면 수동 빌드도 가능하다.

그럼 이렇게 브랜치를 선택해서 내가 설정한 Workflow에 맞게 빌드할 수 있다.

빌드를 해본다...

안드로이드 빌드는 2분 21초밖에 안걸렸다.

IOS앱 빌드중 실패했다..

그럼 이렇게 메일이 온다.

설정한 Workflow에 의해 배포도 되지 않는다.

 

빌드가 실패한 이유는 무엇일까?

요즘 Xcode 14.3 버전이 말이 많다.

https://stackoverflow.com/questions/75921899/run-custom-shell-script-cp-embed-pods-frameworks

Run custom shell script '[CP] Embed Pods Frameworks'

해결책은 코코아팟을 업데이트 하면 되는 것.

로컬의 CocoaPods를 버전 업그레이드 할 필요없이 여기서 바로 바꿔준다.

이 때 감동받았다. 너무 편해서

두 번째 도전

흠.. "~~~version code that has already been used"

빌드 번호랑 앱 버전을 업데이트 해주어야 한다.

yaml 파일에서 수정하고 xcode에서 수정하면 된다.

실패하면 이런식으로 뜬다.

세 번째 도전 (성공)

빌드 버전, 앱 버전도 바꿨고 IOS도 빌드도 가능해졌다.

이번에는 PR을 날려본다.

아까 설정한 build triggers에 의해 자동으로 작동한다.

(내가 원한 workflow는 아니다.)

약간의 시간이 지나고.. App store distribution을 하고 있다고 한다..

모든 체크가 패스됐다.

성공했다고 다운로드 링크가 있는 메일이 온다.

플레이스토어에도 알아서 새 버전으로 올려 검토를 기다리는 모습이다.

TestFlight 에도 잘 올라간 모습이다. (위에서 검토 설정 안하고 Testflight 설정만 함)

후기 및 정리

사실 직접 해보기 전에는 Github-flow 전략에서 CI/CD를 진행하는게 조금 애매하다고 생각했다.

아니 main브랜치랑 feature 브랜치밖에 없는데 어떤 식으로 해야하나?

main에 병합될 때마다 바로 배포를 해버리면 내부테스트는 어떻게 해야하나?

그럼 main에 병합되면 테스트까지만 배포하고 프로덕션에는 수동으로 올려야하나?

Continuous deployment는 불가능하고 Continuous delivery 까지만 되는건가?

 

하지만 직접 사용해보니 크게 문제될 것은 아닌 것 같고 오히려 나만의 워크플로우를 설정해주면 그만이다.

Build Trigger가 결국은 핵심인 것 같다.

Watched branch patterns, Watched tag patterns을 이용해서 feature 브랜치에 코드가 푸시되면 test까지만 하고

그 feature 브랜치에서 PR을 날리면 플레이스토어와 앱스토어의 내부 테스트, TestFlight 까지 배포해주고

QA가 잘 끝나고 master 브랜치에 병합이 된다면 프로덕션으로 자동으로 올리게 할 수도, 수동으로 올릴 수도 있다.

또한 태그를 이용해서 특정 상황에 맞게 할 수 있을 것 같다.

 

직접 해보니 이건 신세계다.

왜 지금까지 미뤘는지 모르겠다.

github actions + fastlane은 어떤 기능일지 궁금하다.

 

그리고 10분도 안걸렸다.

한 달에 500분 무료이면 50번이나 진행할 수 있다. 

역시 무료티어도 차고 넘치는 것 같다.

---

이제 CI/CD 환경이 구축이 완료되었다고 볼 수 있지만, 중요한 Test가 빠졌다.

지금은 빌드만 성공하면 되니 앱에 오류가 있는 상황에도 그냥 넘어갈지 모른다.

테스트 코드를 작성해서 좀 더 안전하게 만들어야 한다.

 

다음 편인 "담타 프로젝트 관리하기 3-3"편을 쓰게 된다면 github actions + fastline에 관해 쓸 에정이고,

다음 시리즈인 "담타 프로젝트 관리하기 4~"편에는 테스트 코드, 테스트에 관해 다룰 예정이다.