모빌 (MoBil)
카카오의 모바일 앱 CI / CD 플랫폼
이 글은 카카오 테크 블로그에 올라온 내용을 똑같이 브런치로 편집만 한 내용 입니다.
http://tech.kakao.com/2016/04/21/mobil/
하나의 모바일 앱이 마켓에 출시되기까지는 수많은 빌드와 배포 과정을 거치게 됩니다. 더 자주, 더 빠르게, 더 높은 품질의 서비스를 출시하기 위해서는 효율적인 빌드와 배포는 필수적입니다.
높은 품질 + 좋은? 서비스카카오에는 모바일 앱을 지속적으로 통합하고 지속적으로 배포하기 위해 자체 개발한 플랫폼 모빌(MoBil)이 있습니다.
모빌의 시작
모빌의 초기 버전은 2013년에 개발이 시작되었습니다. 당시 서버 애플리케이션의 빌드와 배포는 자동화가 많이 적용된 상황이었지만 모바일 앱은 그렇지 않았습니다. 일부 조직에서는 CI 환경을 구축해서 활용했지만, 로컬 빌드 후 수동 배포하는 경우가 많았습니다. 또한 배포 방식이 다양하다 보니 개발자와 QA 엔지니어 사이의 커뮤니케이션 비용이 많이 발생하고 있었습니다. 이렇게 모바일 앱의 빌드부터 배포까지 전체 릴리스 과정이 통합되어있지 않아 비효율적인 부분이 많았고, 릴리스 과정이 매끄럽게 진행되지 않는 문제가 있었습니다.
미리 살펴본 도구들
- Greenhouse CI, CircleCI : 모바일 앱을 위한 CI/CD 도구들이 속속 등장하고 있지만, 모빌을 개발하기 시작할 당시에는 모바일 앱에 특화된 도구는 전무했습니다.
- Jenkins : CI 도구의 대명사인 Jenkins를 활용할 수 있지만, Jenkins 만으로는 전체 릴리스 과정을 매끄럽게 이어 주기는 어려워 보였습니다.
- 기타 배포 도구 : 애플에 인수된 TestFlight이나 Twitter Fabric에 통합된 Crashlytics Beta라는 도구도 있었지만, 앱 배포 과정에만 특화된 도구였습니다.
빌드부터 배포까지 전체 릴리스 단계를 모두 포함하는 입맛에 맞는 도구는 찾지 못했고, 결국 직접 개발을 하기로 결정했습니다.
답답하니 내가 친다.. 아니 만든다모빌과 함께하는 모바일 앱의 빌드 및 배포
모빌이 동작하는 흐름을 동영상으로 먼저 살펴보겠습니다. 자세한 내용은 이어집니다.
목표와 원칙
EASY
도구를 사용하기 쉽게 만드는 것은 모빌 개발을 시작하면서 정한 대원칙입니다.
모빌을 통해 CI, CD를 적용하려고 할 때 최대한 쉽게 적용할 수 있도록 만들자.
아무리 좋은 도구라도 진입 장벽이 높거나 혹은 귀찮게 여겨진다면 그 도구는 이미 좋은 도구가 아니라고 생각합니다. 빌드를 위한 최소한의 정보(저장소, 빌드 설정)만 입력하면 바로 모빌을 사용할 수 있게 만들었습니다.
개발자는 개발에만 집중할 수 있게 하고, QA와 테스터는 테스트에만 집중할 수 있도록 하자.
비효율적인 부분이나 투명하지 않은 프로세스는 CI, CD를 적용하면 대부분 해소가 되는 부분이었습니다. 따라서 본연의 업무에 충실할 수 있게 되고 생산성은 높아집니다. 릴리스 과정에서 자동화할 수 있는 부분은 모두 자동화하는 것을 목표로 모빌 개발을 시작했습니다.
누구나 쉽게 빌드를 실행할 수 있도록 하자.
CI에서는 모든 커밋에 대해 빌드를 하는 것이 원칙이지만, CD에서는 조금 달라집니다. 모든 커밋에 대한 빌드 산출물(모바일 앱)이 QA나 테스터에게 의미 있는 산출물은 아니기 때문입니다. 모빌은 모든 커밋에 대해 빌드를 하고 사용자가 직접 원하는 빌드를 찾아서 앱을 설치 후 사용하는 방식이 아닌, 조건에 맞는 특정 커밋이나 정해진 시간에 빌드를 할 수 있는 방식을 선택했습니다. 즉, CI 빌드를 기본으로 하되 다양한 방법으로 선택적 빌드를 실행할 수 있도록 개발되었습니다.
모빌은 개발자가 아니더라도 권한이 있는 사용자에 의해 빌드 실행이 가능하기 때문에 Agile Testing을 할 수 있습니다. 차기 릴리스를 위한 개발이 모두 완료되었을 때 UAT(User Acceptance Test)가 진행되는 것이 아니라, 개발 진행 중에 QA 엔지니어가 함께 참여해서 Feature 단위로 개발이 완료될 때마다 즉시 빌드를 하고, 테스트를 할 수 있는 환경을 제공합니다.
빌드 산출물을 쉽게 배포하고 설치할 수 있도록 하자.
빌드 후 산출물은 모빌의 저장소에 저장됩니다. 하지만 이 상태는 사용자에게 배포된 상태가 아닙니다. 모빌은 사용자에게 빌드 산출물을 설치할 수 있도록 하기 위해 배포 기능을 따로 제공하고 있습니다. 배포 방식은 여러 가지 유형이 있으며 사내 CBT 배포(앱 출시 직전 테스트를 위한 배포), 공개 배포(앱 개발 중이지만 관심 있는 사용자는 받아 수행해볼 수 있는 배포), 비공개 배포(공개하기 힘든 상황에서 특정 사용자에게만 배포) 등으로 나눌 수 있습니다. 배포 유형에 따라 노출 기준이나 설치할 수 있는 대상 사용자가 달라집니다.
모빌의 배포는 OTA(Over The Air) 방식으로 진행됩니다.
애플 앱스토어나 구글 플레이스토어처럼 카카오 앱센터(모빌 iOS/Android 클라이언트)라는 사내 전용 앱으로 배포가 이루어집니다. 카카오 앱센터에서는 앱의 최신 배포 버전뿐만 아니라 지난 배포 이력을 확인할 수 있으며 특정 버전의 앱을 설치할 수 있습니다. 또한 카카오톡을 이용하여 사내 사용자들끼리 쉽게 공유할 수 있는 기능도 제공하고 있습니다.
지금 카카오에서는
와 같이 배포하는 것이 아니라
모빌에서 받으세요
한마디면 끝입니다.
+보너스
카카오톡을 이용한 앱 배포 알림모빌의 아키텍처
모빌은 크게 앱을 등록하고 빌드하고 배포하는 과정을 관리하는 웹 서비스와, 안드로이드&iOS용 클라이언트인 카카오 앱센터로 구성되어 있습니다. 그리고 빌드 관리를 위한 Jenkins 서버와 실제 빌드가 실행되는 MacPro로 구성되어 있습니다.
빌드 실행 이벤트 발생 시 모빌에 등록된 빌드 설정으로 Jenkins에 Job이 생성되고 빌드가 실행됩니다. 빌드 실행 과정에서 Jenkins는 일종의 Stub 역할 만을 하게 됩니다. 실제 빌드는 Jenkins의 Slave Machine으로 등록되어 있는 MacPro 장비에서 통합 빌드 스크립트에 의해 빌드가 실행됩니다. 빌드가 완료되면 빌드 산출물은 케이지(KAGE - 카카오가 자체 개발한 분산 스토리지 플랫폼)에 저장되며, 카카오 앱센터로 자동 또는 수동으로 배포됩니다. 그리고 모카(MOCA - 카카오가 자체 개발한 모바일앱 크래시 분석 시스템)로 빌드 산출물을 배포하게 됩니다. 모카는 Crashlytics처럼 앱 크래시 분석을 위해 만들어진 사내 플랫폼으로 모카에서 앱 크래시 분석을 위해 필요한 빌드 산출물(iOS dSYM, android mapping.txt)을 매 빌드 시 모카로 자동으로 배포하게 됩니다.
모빌은 사내 이슈 트래킹 시스템인 JIRA와 연계가 가능합니다. 대부분의 카카오 서비스들은 JIRA를 통해 버그나 개발 이슈들을 관리하고 있습니다. 모빌에서 코드 <-> 빌드 <-> 관련된 이슈 정보를 한눈에 쉽게 파악할 수 있도록 JIRA와 연결 기능을 점차 확장해 나가고 있습니다.
모빌의 미래
UI Test Automation on Real Devices
모빌의 다음 단계는 실제 기기에서 UI 테스트를 자동화하는 기능입니다. 모빌에서 빌드 후 다양한 종류와 버전의 실제 기기에서 자동화된 테스트를 수행하고, 테스트 결과물을 받아볼 수 있도록 하는 것이 목표입니다만, 아직 모빌의 대원칙인 "쉬운" 방법을 찾지 못해서 열심히 찾아보고 있는 중입니다.
모빌 사용기
모빌을 적용한 서비스 조직의 경험담으로 마무리하겠습니다.
카카오톡
모빌이 없으면 안 될 정도로 많은 부분을 제공해주었습니다. 빌드 말리는(?) 시간도 단축되었고, 빌드 공유 또한 간편해져서 일의 효율을 한층 높여주었어요. @trudy
QA를 진행함에 있어 '빌드의 실시간성'과 '배포 원스탑' 부분이 가장 크게 와 닿았습니다. @yama
원샷으로 빌드 및 업로드 관리가 편리해졌고, PHASE별 앱 빌드 및 관리가 편리해졌습니다. @shanks
카카오택시
개발 담당자가 배포를 하지 않아도 담당 QA분이 배포를 하거나, 배포 이력을 확인할 수 있어서 편합니다. @damon
카페앱
현재까지 작업된 버전을 tag로 만들면 자동으로 빌드를 해주고, 배포를 직접 하지 않아도 돼서 편리합니다. @young
간단한 조작으로 빌드와 배포를 한 번에 할 수 있어 편해졌습니다. @bruno
다음앱
모빌 사용 후로는 Github에 직접 들어가서 브랜치를 찾아 수정내역을 파악해볼 필요 없이, 빌드된 아이템에서 바로 커밋 내역으로 찾아 들어가 수정된 부분을 체크해볼 수 있어 좋다. 또한 제한된 테스터 만으로 테스트할 수 있는 환경 조성도 쉽게 할 수 있어 테스트 환경을 구성하는 것도 편리하다. 그리고 QA종료 후 릴리즈 빌드 생성을 버튼 하나로 할 수 있고, Rollback 빌드도 쉽게 생성되어 배포관리도 편해졌다. @ted
github의 commit 중 하나를 선택하여 빌드할 수 있어 편리했습니다. 특히 빌드 결과물을 다른 팀에 쉽게 공유할 수 있어 좋았습니다. @warren
카카오티비
Github 연동으로 변경사항을 파악할 수 있고, 언제든 원하는 빌드를 설치해서 확인할 수 있어 업무의 효율성과 편리성을 높여줬습니다. @libby
이 글은 카카오에서 모빌을 포함한 다양한 개발 플랫폼을 개발&운영하며 틈틈이 회사 텃밭을 일구고 있는 Benedict.lee를 졸라서 쓴 글입니다. 저자가 2013년 데브온에서 발표한 Code Review - What, 2 Whys & How는 몇 년이 지난 지금 봐도 - 발표를 직접 듣고 싶은 - 훌륭한 자료입니다.
+ Brunch의 글 내용 일부 수정 및 가공은 같은 팀인 Bart(이철민)이 했습니다.
