이 글은 정보성글이라고 하기엔 애매한 글입니다.
자동화를 구축하면서 느끼고 배운 부분을 적는 글이라서, 내용이 유익하지 않을 수도 있습니다. (?)
이 글에서 얻으실 수 있는 정보성 글은 Code Signing 과 PROVISIONING PROFILE 인증 부분입니다.
오늘은 자동화 서비스 중 하나인 Bitrise를 이용하여 자사의 자동화 배포를 구축해본 내용을 간단하게라도 공유하고 싶어서 글을 작성하게 됐다.
필자는 작은 스타트업에서 현재 7개월째 iOS 개발자로 일을 하고 있다.
필자의 회사에서는 매 주 수요일마다 세미나를 하게 되는데, 각 주마다 돌아가면서 하나의 주제로 준비를 하여 발표하는 형식입니다. 이때 저는 "자동화를 우리 회사에서 적용해보자" 라는 주제로 다른 회사들의 사례나 Fastlane 등의 자동화 툴을 실제로 사용한 것들을 발표했었다.
그리고 세미나가 끝날 때쯤, "발표를 했으니 그럼 우리 회사에 자동화를 구축해보죠!" 라는 말이 돌아왔다.
따라서 한달정도를 공부하고 구축하게 되었다.
자동화 구축하면 좋은게 먼데요?
머 그리 대단하게 구축한 것은 아니고, 아카이빙과 업로드까지 해주는 플로우로 자동화를 진행하게 했다.
사실 이 과정이 사람이 수기로 한다면 생각보다 많은 리소스가 들어간다. 아카이빙을 진행하는 그 시간에는 코드 작업을 할 수도 없고, 만약 내 컴퓨터가 그리 좋지 않은 컴퓨터라면 시간은 배로 들어가게 된다.
또한, 빌드 성공과 실패여부를 일일히 확인하고 알려줘야 하기 때문에, 이게 자연스레 업무 스트레스로 돌아오게 되었다. 자동화를 구축하게 된다면, 이 업무 스트레스를 한번에 날려주게 된다.
Git Clone 부터 빌드, 아카이빙하고 업로드 , 후에 성공/실패 여부를 푸시까지 해주니 사실상 이 시간에는 멀 해도 남는 시간이 되는 것이다.
따라서 자동화를 구축해야겠다고 생각했다.
근데 왜 많은 자동화 서비스 중에 Bitrise를 선택한 걸까?
Bitrise?
Bitrise는 간단한 UI로 CI/CD 환경을 구축할 수 있고, 많은 익스텐션들이 존재하여 붙혀넣기만 하면 되는 구조이다.
단점으로는 빌드 분 당 크레딧으로 계산을 하고, 크레딧을 다 사용하면 돈을 지불해야 한다는 단점이,, (그래도 상당히 싸다.)
그리고 마스코트가 귀엽다.
CI/CD가 무엇인지는 다음 글로 정리해보겠다.
여러 가상 자동화 툴이 있지만, 직관적으로 툴을 구성할 수 있다는 점에서 우리 개발진들은 선택하게 되었다.
사실상 자동화 구축을 처음 해보았기에 너무나도 많은 시행착오가 존재했다. 슬슬 알아보도록 하자.
초반엔 쉬웠던 과정
위에서 말했듯이 직관적인 UI로 빌드 자동화 과정을 짜다 보니 생각보다 간단해보였다. 실제로 간단했었다.
이렇게 원하는 기능의 워크플로우만 추가해서 작동할 수 있게 돌리면 되는 것이기 때문이다.
사실 빌드까지는 한글, 영어로 검색해도 어디에서나 나온다.
그런데, 빌드 이후에 앱스토어에 등록하는, 즉 테스트플라이트로 업로드하는 과정에서는 약간의 정보의 미숙이 존재한다.
사실 찾아보면 나오긴 하는데, 다 영어라,,(필자는 영어를 잘 못한다.)
막혀버린 과정과 흘러가는 시간..
막힌 부분은 바로 이 사진에서 보이는 코드 사이닝 부분이다.
코드 사이닝이란, 빌드 하려는 앱의 사이닝을 맞춰주는 역할을 한다.
사실 이부분에서 시간이 제일 오래 걸렸다.
이 글을 읽는 분들은 시간을 아끼기 바라는 마음에서 막혔던 부분을 얘기해보고자 한다.
1. 코드 사이닝은 API를 꼭 타길 바란다.
API를 타라는게 무슨 소리냐 함은, Bitrise 상에서의 코드 사이닝 방법은 총 2가지가 존재한다.
- api-key: Bitrise Apple Service connection with API Key.
- apple-id: Bitrise Apple Service connection with Apple ID.
API를 사용하여 인증하는 방법과 Apple ID를 통해서 인증하는 방법 2가지이다.
필자는 처음에는 Apple ID를 통해서 인증하려 했었다.
하지만 생각보다 진행이 많이많이 안됐었다.
failed to manage code signing: failed to get valid certificates: not found any of the following IOS_DISTRIBUTION certificates on Developer Portal:단골 사이닝 버그부터 시작해서,,사이닝할때 여러 팀이 있으면 또 그것도 캐치를 해줘야 하고,,여러모로 에러 요소가 끊이질 않았다.
그렇게 ID로 계속 시도를 몇 주 하다가, 더이상은 안될 것 같아서 API로 사이닝 시도를 했었다.
API생성 방법은 다음과 같다.
- AppstoreConnect에 들어가서 'Users and Access' 페이지를 들어간다.
- Users and Access 페이지에서 Keys 섹션으로 들어가 새로운 키를 발급 받는다.
- 원하는 이름을 짓고, 허용하는 범위를 지정해준다.
- API p8 파일은 한번밖에 다운받지 못한다. 따라서 다운받은 파일을 고이 잘 모셔두자.
이렇게 생성한 API를 Bitrise 계정에 등록한다.
Add API Key를 누르면
해당되는 페이지의 정보를 입력하거나, p8 파일을 업로드 한다.
이러면 일단 기본적인 사이닝을 위한 API 통신 구축은 완성했다.
이외에도 코드 사이닝 파일을 올려두어야 하는데, 이 부분은 간단하게 설명하겠다.
Certificates, Identifiers & Profiles 클릭
Profiles 클릭 하고 추가 버튼 클릭
Distribution을 App Store로 해주어야 테스트 플라이트 업로드 시 인증됩니다.
다 만들고 파일 다운로드 후에
프로비저닝 파일에 업로드 하면 됩니다.
아래 부분의 코드 사이닝 파일은
요 탭에서 추가하는데
이거 선택하시고 해야 사이닝 올바르게 진행될껍니다.
이렇게 해주시고 파일 생성하고 업로드 하면 인증은 끝!
2. 어렵게 생각하지 말자.
원래 급할수록 돌아가라 라는 말이 있지 않은가?
사실 빌드 자동화를 진행하면서, 듣도보도 못한 개념들이 너무 많이 등장했다.
사이닝은 솔직히 Xcode 키면 자동으로 잡히길래 "아 사이닝은 알아서 해주는 거구나" 라는 생각으로 진행했다가 사이닝 부분에서 큰 코 다쳤고, 나머지 아카이빙 빌드 부분에서도 마냥 쉽다고 생각했던 것들이 막히니까 급해지기 마련이었다.
그런데 막상 해결되는건 끙끙 잡고 있을때가 아닌, 생각지도 못한 부분에서의 해결책이 등장하곤 했다. 결론은, 해결이 안될땐 잠깐 쉬어가는 타임을 가져보자 이말이다.
빌드 자동화를 진행해보며
사실 빌드 자동화가 왜 필요할까 라는 의문에서 시작했다.
빌드는 개발자가 할 수도 있고, 그게 얼마나 오래걸린다고 자동화까지 하나? 라는 생각.
그렇지만 실제 서비스를 운영하는 회사에서 이런 생각은 크나큰 오점이었다.
빌드를 하는 그 시간동안 개발은 커녕, 컴퓨터 자체를 만지기 힘든 상황이 나오기도 하고, 만약 빌드를 야근을 하고 한다면 자연스레 퇴근 시간은 밀려지기 마련이었다.
개발 환경을 더 좋게 하기 위해서는 필수적으로 빌드 자동화를 진행해야겠다라고 느껴진 프로젝트였다고 생각한다.
