소개
작성자 및 글을 쓰게된 계기 소개
안녕하세요.
헤렌에서 iOS개발을 담당하고 있는 넬로라고 합니다 ~!
최근에 제가 iOS개발의 인프라 개선을 위해 fastlane을 도입하고,
배포자동화를 구축하는 과정에서 느꼈던 점들과 도입하게된 배경 등을 소개드리고자 글을 쓰게 되었습니다 !!
보시다가, 의문이 드는 부분들은 피드백을 주시면 정말 감사하겠습니다 
도입배경
fastlane을 도입하게된 배경
CI/CD구축이 안된 전의 경우, 기본적인 iOS의 배포 과정은 다음과 같았습니다.
순서 | 작업내용 | 환경 | 변수상황 | 변수발생원인 |
1 | 업로드용 파일생성 작업
(Archive) | Xcode | - | - |
2 | AppStoreConnect에
업로드 | Xcode | 1. 통신실패
(TimeRequestFail)
2. 설정오류 | 1. 없음
2. 정책에 맞지않는 설정 값 발견 |
3 | AppStoreConnect에
업로드 반영완료 | AppStoreConnect | - | - |
4 | 검수요청 | AppStoreConnect | - | - |
5 | 심사완료 및 출시대기 | AppStoreConnect | 심사거절 | 정책에 맞지않는 기능등이 발견 |
6 | 출시진행 | AppStoreConnect | - | - |
7 | 출시된 버전 스토어에
반영완료 | AppStore | - | - |
그리고 해당 과정에서 AppStoreConnect에 업로드 하는 과정이 제일 까다로웠습니다.
다음 버튼 한 번 누른다고 진행되는게 아니고, 몇 번의 프로세스를 거쳐야하고
그마저도 TimeRequestFail이 나버리면 다시 처음부터 해야했습니다.
기분이 절로 좋아지는 화면.jpg
힘이 쫙빠지는 화면.jpg
물론 아카이브 파일 생성하는 과정에도 빌드를 제대로 못하기 때문에 대기해야했습니다.
이와 같은 한 번의 출시로 발생되는 대기시간이 적게는 30분 많게는 2시간까지도 소요됐습니다.
평균적으로 한 번 출시의 대기시간이 1시간이고,
주 마다 업로드 하는 횟수를 5회정도로 가정 했을 때,
한 달의 평균 대기시간은 20시간입니다.
근로시간 8시간 기준 2일이 넘는 시간이 한 달마다 소요되고 있었습니다.
그리고 단순한 시간의 문제뿐만아니라 영향받는 개발자의 정신적인 피로도,
출시에 대해 영향을 받는 동료들 까지 생각하면 개선이 꼭 필요한 문제라고 생각이 들었습니다.
선택과정
fastlane을 선택하게된 이유
여러모로 검색해보고 고민해본 결과, 얼핏 공부했던 CI/CD의 개념이 생각났습니다.
그리고 iOS 배포자동화를 키워드로 검색해보니,
fastlane 에 대한 내용이 많이 나왔습니다.
이것이 무엇인고? 하고 알아보니,
fastlane
is the easiest way to automate beta deployments and releases for your iOS and Android apps. It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.
It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.iOS를 위한 가장 쉬운 배포 출시 자동화 오픈소스 프로젝트라고 소개하고있습니다 !!
심지어 인앱 스크린샷도 생성해주고 코드사이닝부터 앱스토어에서 검수요청 및 출시 처리하는 것 까지!!
바라지도 않았던 부분까지 자동화를 해준다기에 망설임없이 선택하였고,
이미 많은 분들이 사용하고 있다는 점도 크게 기여했습니다.
도입과정
fastlane을 헤렌에 맞게 도입하는 과정
fastlane이 좋은 것은 분명했으나, 헤렌에 맞게끔 도입하는 것도 저에겐 쉽지않은 일 이였습니다.
우선, 설치 및 설정하는 것은 쉬웠습니다.
그러나 문제는 인증관련 부분에서 발생했습니다.
처음 제가 왔을 때 인수인계를 회사계정으로 가입된 애플 ID를 공유받았는데요 !!
여기에는 개인과 기업이 따로 있습니다.
그래서 인지 development로 certification을 생성할 땐 개인 이름으로
distributuion을 위한 appstore certification은 기업 이름으로 생성되었고,
fastlane match과정에서 개발용 인증서는 잘 찾는데, 배포용 인증서는 인식하지 못했습니다.
처음에는 인증서 자체에 문제가 아닐까하여, 구글링하면서 얻은 정보들을 토대로
키체인 등록부터 nuke 명령어로 파기 후 다시 설정하는 등을 시도해보았으나, 해결이 되지 않았습니다.
그리고 다시 생각해보니, 개인이름과 기업이름으로된 하나의 인증서가 가장 마음에 걸렸습니다.
“회사 계정 하나를 왜 모든 iOS개발자가 공유해서 쓰고있지? 개인 계정을 회사에 귀속시켜서 사용하는게 맞는 거 아닌가?”라는 생각이 들었고, 이에 저는 Apple Developer 사이트에서
회사 계정으로 로그인 후 제 개인 계정을 초대했고,
다시 제 개인 계정으로 로그인하여 처음부터 다시 인증 설정을 하였습니다.
그리고 다시 fastlane의 설정을 하는 fastfile을 작성할 때는 확인했던 타 블로그의 글 들이 아닌 공식문서의 내용만 가지고 시작했습니다.
그 결과, 무사히 인증문제가 해결되었고 드디어 본격적으로 fastlane 설정을 시작할 수 있었습니다.
그리고 설정하기전에 앞서, 헤렌의 배포 분기는 다음과 같습니다.
1.
테스트 플라이트 테스트를 위한, Debug 앱 배포
2.
테스트 플라이트 테스트를 위한, Release 앱 배포
3.
검수 요청 및 앱스토어에 출시를 위한 Release 앱 배포
여기에 맞게끔 3가지의 lane 을 구성했습니다.
명령어 단축을 위해 터미널의 alias 기능을 사용하여,
1.
testDebug
2.
testRelease
3.
appstore
3가지 키워드를 터미널에 바로 입력하면 전체 커맨드를 사용할 필요 없이 각각 맞게끔 배포를 자동으로 진행하도록 했습니다.
또 한, 현재 서비스 중인 앱 이 공비서CRM과공비서예약 2가지이고 추가적으로 늘어날 수 있기 때문에
ENV 설정의 번들 ID등 몇 개만 수정하면, 모든 앱에 대응 가능하도록 fastfile 을 최대한 모듈화해서 작성했습니다.
하다보니 공식문서에 slack연동에 관한 부분도 있어서, 이 부분도 헤렌의 slack webhook의 slack url을 가져와,
각 배포에 과정에서 발생되는 오류와 결과에 대한 모니터링을 slack을 통해 할 수 있도록 설정했습니다~!
도입결과
fastlane 도입으로 인하여 얻게된 결과
도입하는 과정이 생각보다 상당히 힘들었지만, 결과가 너무나도 좋아서 많은 보람감을 느꼈습니다.
우선, fastlane을 통해 배포를 하면 다음과 같이 시간을 얼마나 아꼈는지 알려줍니다~!
각 step의 액션별로도 소요 시간이 나오고, 전체 시간을 얼마나 save 했는지 알려줍니다!!
그 외에도 제가 느낀 가장 큰 좋았던 점을 꼽자면 다음과 같았습니다.
1.
배포 시켜놓고 모니터링을 안해도 된다. (혹시라도 오류가 나면, 슬랙을 통해 이녀석은 무료로 알려줍니다)
2.
버전,빌드 번호관리를 자동으로 카운팅할 수 있기 때문에 버전관리가 편하다.
3.
배포 하는동안, 다른 작업을 할 수 있다 !!
4.
테스트용 앱과 실제 운영용 앱을 잘못 올리는 실수 자체를 할 일이 없어진다.
5.
생각보다 많은 부분을 커스텀해서 출시할 수 있다.
a.
사용하고 있는 몇가지 옵션들을 소개합니다..!
force: true,
reject_if_possible: true,
skip_metadata: false,
skip_screenshots: true,
release_notes: {
"default" => "기본 릴리즈 노트",
},
submit_for_review: true,
automatic_release: true
submission_information: {
add_id_info_uses_idfa: true,
add_id_info_serves_ads: true,
add_id_info_tracks_install: true,
add_id_info_tracks_action: false,
add_id_info_limits_tracking: true,
export_compliance_encryption_updated: false,
}
Ruby
복사
여기에 추가적으로 기존에 사용중인 젠킨스와 연동하여,
백엔드에서 배포할 때 같이 배포될 수 있도록 완전 자동화를 한다던가,
GitAction을 사용하여 Git에서 PR후 메인 branch에 merge할 때 배포 트리거를 건다거나 등의
다양한 입맛대로 진화(?)가 가능합니다~!
이렇게 fastlane 도입 이야기를 소개드렸는데요 !!
그 밖에, firebase의 performane,crashlytics,remoteconfig 기능 도입하기
BDD를 위한 Nimble,Quick으로 테스트 코드 도입하기 등
헤렌 iOS에서는 개발 인프라 개선을 위해 많은 시도를 해보고 있습니다..!
기회가 된다면 해당 후기들도 소개드리도록 할게요 !!
여기까지 읽어주신 것에 대해 진심으로 감사의 말씀 드리면서 이만 마치도록 하겠습니다 !
아 참!! 현재 폭풍성장중인 헤렌과 같이할 헤더분들을 찾고있습니다~!
참고
