안드로이드 Bitrise 도입기
2탄은 없을 수도 있는 1탄
안녕하세요.
크몽에서 안드로이드 앱을 만들고 있는 팀원 중 한 명인 Mickey입니다.
크몽에 입사 한지는 이제 9개월이 되어 가네요.
이렇게 갑자기 글을 작성하게 된 계기는.. 개인 블로그도 운영을 시도해보고 했었지만, 쉽게 적히지 않는 기술 블로그...
하지만 마침! 크몽에서 기술 블로그를 운영하고 있고, 소소하게 공유할만한 자그마한 일거리도 있었고 해서 공유하는 차원에서 글을 작성해 봅니다.
제 첫 기술 블로그의 주제는 Android Bitrise 도입기입니다.
제가 크몽에 입사하고 나서 챕터 내의 목표를 공유받았는데, 그중 하나로 CI/CD 도입하기 가 있었습니다.
(제 경험상 CI/CD 는 지난 회사들을 돌이켜보면 니즈는 항상 있었지만, 이리 치이고 저리 치이고 하다가 결국 제대로 도입을 해본 적이 없었습니다.. 단 한번 Jenkins를 맛보고 호되게 고생한 기억이 있습니다.)
챕터 내의 목표는 담당자가 정해져 있다기보다, 시간적 여유가 생긴 챕터원이 맡아 진행을 하는 방식으로 진행되었습니다.
마침 저는 입사하지 얼마 되지 않아서 프로젝트를 맡아 진행하던 타 챕터원들에 비해 상대적으로 시간적 여유가 있었고, 개인적으로도 관심은(?) 있던 CI/CD 도입을 맡아 진행하기로 했습니다.
Why Bitrise?
제목을 보시다시피 저희는 최종적으로 CI/CD 서비스는 Bitrise를 선택했습니다.
Jenkins, Travis CI, Circle CI 등등 많은 서비스들이 있었지만, 가격 & 사용성 & 속도를 다 제외하고도 Bitrise를 선택한 이유는 모바일 최적화였습니다.
(Jenkins 같은 경우는 너무 호되게 당한 기억이 있어서 이번에는 눈길조차 주지 않았지만..)
Bitrise 가 가장 강력하게 어필하는 부분이 모바일 최적화였고, 저희는 앱을 만드는 모바일 개발자다 보니 자연스레 끌렸습니다. 레퍼런스와 플로그인 같은 게 아직은 부족한 걸 알면서도 우리도 이제 막 CI/CD를 도입하는 입장에서 한번 사용해보고 아니면 바꾸지 뭐!라는 생각으로 저는 Bitirse를 선택해서 챕터 내에 공유했습니다.
다행히도 챕터원들은 모두 Bitrise 사용에 동의해주셨고, Bitrise를 선택해서 배포 자동화를 설정해 보기 시작했습니다.
Bitrise 선택 후 Flow 구성까지
놀랍게도 너무 예쁜 UI와 하루하루 업데이트되는 플러그인 형식의 (Bitrise에서는 step이라고 표현합니다.) step들이 보였습니다.
Bitrise Step(plugin)
사실 다른 서비스들을 사용해보지 않아서 모르겠지만, 모바일 최적화라는 워딩을 괜히 어필한 게 아니구나 싶은 생각이 들 정도로, 내가 원하는 step 들을 딱딱 꽂아 넣으면 정말 어렵지 않게 apk 추출하는 것 까지 할 수 있었습니다.
사용성이 생각보다 괜찮았기 때문에 챕터 내에 공유드리고, 요구사항을 간단하게 정의한 뒤 CI/CD 첫 번째 목표 플로우를 아래 그림처럼 구상했습니다.
매일 아침에 자동 빌드
Develop branch merge or PR event / tag push 트리거
Unit/UI 테스트
빌드 성공/실패 시 slack 알림
playstore 업로드
크몽 Android 팀의 CI/CD Flow_1차Bitrise 설정
요구사항을 정의하고 Flow를 구상해봤으니, Bitrise에 설정을 해야겠죠.
설정이 쉽다고는 하지만, 정말 많은 시행착오가 있었습니다.
설정 초기 당시...요구사항에 테스트 코드 검증이 있지만 저 당시에는 테스트 코드가 없었어서.. 간단하지만 테스트 코드도 만들어야 했고, 예상치 못한 오류로 빌드가 실패했을 때 slack 알림이 오지 않아서 이를 직접 yml 파일을 수정하기도 했습니다.
(Bitrise에서 설정한 값들은 별도의 yml 파일로 실시간으로 작성되어, 다운로드하거나 반대로 이미 저장된 yml 파일 내용을 붙여 넣을 수 있습니다.)
한번 빌드하는데 처음에는 5분, 10분 나중에는 20분이 넘어가면서 테스트 빌드를 돌려놓고 안마의자에 몸을 맡기고 오기도 했네요.
당연히 될 거라도 생각했던 빌드가 Faild 떠 있는 걸 보고 좌절하기도 하고.. 또 20분을 언제 기다려...
결국 나중에는 요구사항 단위로 분할해서 테스트하고 하나로 합치기도 했습니다.
요구사항에 맞춰서
저희 팀의 큰 요구사항은 이랬습니다.
매일 아침에 자동 빌드
Develop branch merge or PR event / tag push 트리거
Unit/UI 테스트
빌드 성공/실패 시 slack 알림
playstore 업로드
이 항목들을 기준으로 설정을 진행했습니다.
매일 아침에 자동 빌드
Bitrise 에는 Builder Schedule을 설정할 수 있어서 정말 손쉽게 데일리 빌드를 설정할 수 있었습니다.
Build Schdeule저희는 매일 아침 오전 8시에 Develop 브런치를 기준으로 자동 빌드를 시작합니다.
이벤트 트리거
이벤트 트리거 자체도 정규식 pattern을 입력해서 쉽게 설정할 수 있었습니다.
Develop Branch 이벤트는 test -> build 까지만 수행하고 TAG 이벤트는 playstore 업로드 step까지 가도록 구현했습니다.
이 부분에서 매 릴리즈 때마다 versionName/Code 수정하는 일도 줄이고, HumanError를 방지하는 차원에서 별도의 shell script step을 추가해서 push 된 TAG를 파싱 해서 build 할 app bundle의 verion 정보를 설정해 주는 작업도 추가했습니다.
릴리즈 날 담당자분은 배포할 최종 커밋에 태그를 푸시하면 태그에 명시된 앱 버전과 앱 버전 코드로 변경되어 Plystore에 배포됩니다.
Unit/UI 테스트
아직 크몽 안드로이드 앱의 테스트 코드는 많이 없지만..(테스트 코드 역시 이제 막 도입을 시작했습니다.) 이제 곧 많아질 것이기 때문에!! 추가 해 놓았습니다.
테스트 코드의 결과를 따로 확인할 수 있는 Result 페이지도 빌듯이 생성되어 외부에서도 확인할 수 있습니다.
Test code Report빌드 성공/실패 시 slack 알림
여기서 항상 열 일하는 우리의 끄몽이가 탄생했습니다. 얼큰하게 일에 취한 끄몽이
각 Test step, 빌드 성공/실패 시 팀 내의 slack으로 끄몽이가 알려줍니다.
오늘도 가장 먼저 출근하는 끄몽이app bundle 업로드
이 부분이 사실 CI/CD를 도입한 궁극적인 목적이 아닌가 싶네요.
TAG push 이벤트를 트리거해서 playstore 비공개 내부 테스트에 배포하도록 설정했습니다.
여기서 발생하는 리소스가 굉장히 많이 많이 줄어들었습니다.
지금 저희는 비공개 내부 테스트 트랙에 배포 한 뒤, 배타 -> 프로덕션 순으로 업데이트를 진행하고 있습니다.
하지만, 아쉽게도 트랙 업데이트는 Bitrise에서 구현이 어려운 상황이라 수동으로 해주고 있습니다.
추후에는 어떤 트랙에 배포할지도 커밋/태그 단에서 설정할 수 있도록 업데이트할 예정입니다.
마치며
저희는 Bitrise를 2019년 11월에 도입하여 지금까지 약 5개월째 사용을 하고 있습니다.
설정이 쉽다고는 해도 저희 니즈에 맞춰서 실제 도입까지 많은 시행착오가 있었지만.. 개인적으로는 너무 재밌는 프로젝트였습니다. Bitrise 도입 후 앱 배포 시 들어가는 리소스도 실제로 많이 줄었고, 개인적으로는 Bitrise에서 테스트 코드 돌아가는 시간을 빨리 늘려버리고 싶은 욕심도 조금은 생겼습니다.
아직은 기능적으로 더 업데이트해야 할 사항들이 많지만, 2019년도의 목표중 하나는 도달한 것 같아 뿌듯하네요.
이미 2020년도 목표에도 Bitrise 디벨롭 항목이 있으니, 우리 팀에 맞춰서 많은 업그레이드가 있지 않을까 싶네요. 그래도 2탄이 작성될지는 미지수.
여기까지 시간 내시어 서툰 글을 읽어주신 분들께 감사드립니다.
Android 개발자우리 팀은 크몽과 딱 어울리는 당신을 기다리고 있어요. 우리 함께 크몽을 만들어요!
채용공고 *개발직군 상시 채용중!
