Where who wants to meet someone

[Xcode Cloud] Environment Variables로 API Key 넣어주기 본문

Apple Developer/iOS(Swift)

[Xcode Cloud] Environment Variables로 API Key 넣어주기

Lust3r 2024. 3. 22. 16:32
728x90

들어가기에 앞서..

 

 

진짜.. 너무 많은 일이 있었고 해결하기까지... 힘들었다.

 

앱을 배포하기에 앞서 Xcode Cloud로 빌드 -> TestFlight -> 심사 순으로 가는데, 이제 API키를 어떻게 처리해줘야 하나 고민이 많았다.

 

그냥 단순히 GitHub에 올리고, Private처리하면 되지 않나.. 하기엔 포트폴리오 용도로 공개해야 하는 경우도 있어서 그럴 순 없었다.

 

마침 Xcode Cloud에 Environment Variables로 키 외부 주입이 가능함을 알게 되어 시도해 봤다.

 

 

Customize your advanced Xcode Cloud workflows - WWDC21 - Videos - Apple Developer

Xcode Cloud integrates with Apple Developer tools and services, all major source control management services, and even social...

developer.apple.com

(소개만 해주고 왜 방법은..)

 

main 브랜치에서 3회, 이래선 안되겠다 싶어 판 environmentTest 브랜치에서 14회

 

자꾸 전달하는 인자 문제, 위치 문제, 권한 문제가 연달아 발생했고, 이를 해결하기까지 수많은 시도를 했다..

 

그 끝에 얻은 결과는 아래와 같다.

 

1. Xcode Cloud Environment 설정하기

Environment에 값을 넣어주고(저기서 Secret은 Value를 마스킹 처리해서 log에도 보이지 않게 해주는 것)

 

기존 API키를 하드코딩 했던 부분은 API.plist(예시)에서 값을 받아와 사용하는 것으로 변경.

 

"그럼 Environment 값을 어떻게 API.plist에 넣어주는데?"

 

이 또한 찾아보니

 

https://developer.apple.com/documentation/xcode/writing-custom-build-scripts

 

위 세 부분에서 Script를 실행해서 원하는 작업을 할 수 있는데,
Pre-Xcodebuild가 추가 종속성 등의 작업을 하고, 프로젝트 빌드 직전 단계이기 때문에 저 단계에서 수행해주기로 한다.

 

그래서 일단 만들면 될까, 'ci_pre_xcodebuild.sh'?

 

 

 

Writing custom build scripts | Apple Developer Documentation

Extend your Xcode Cloud workflows with custom build scripts that perform custom tasks or install additional tools.

developer.apple.com

파일만 있어서는 안 되고, 폴더가 필요하겠죠?

 

2. ci_scripts, ci_pre_xcodebuild.sh 생성 및 수정

Create the CI scripts directory
Custom build scripts reside in a directory named ci_scripts that’s located in the same directory as your Xcode project or workspace, and Xcode Cloud runs your custom build scripts with this directory as the root directory.

To create the ci_scripts directory:
1. Open your project or workspace in Xcode and navigate to the Project navigator.
2. In the Project navigator, Control-click your project and choose New Group to create the group and its corresponding directory.
3. Name the new group ci_scripts.

 

xcodeproj 파일이 있는 폴더에 ci_scripts 폴더를 만들고, 그 안에 .sh 파일을 만들어준다.

(폴더, 파일 둘 다 Target 추가하지 않고 생성하자)

 

이후 코드를 다음과 같이 수정해 준다.

 

#!/bin/sh

echo "Stage: PRE-Xcode Build Start"

cd ..

plutil -replace API_KEY -string $API_KEY ./{plist 폴더}/API.plist

plutil -p ./{plist 폴더}/API.plist

echo "Stage: PRE-Xcode Build End"

exit 0

(참고를 위한 사이트: https://scriptingosx.com/2016/11/editing-property-lists/)

 

하나씩 보자,

 

1) echo "Stage: PRE-Xcode Build Start"

- 위 이미지처럼 그냥 단계를 확인하기 위해 해놓은 것이고 없어도 무방하다.

 

2) cd ..

- sh가 실행되면, 현재 폴더는 ci_scripts이기 때문에 API.plist가 있는 곳으로 가야 한다.

- 상위 폴더로 이동해 주자. (아예 여기서 해당 폴더로 이동해도 될 것 같다)

 

3) plutil -replace API_KEY -string $API_KEY ./{plist 폴더}/API.plist

- 해당 위치에 있는 API.plist의 API_KEY 항목을 string 타입인 $API_KEY로 바꿔주는 문구다.

- API_KEY에는 API.plist의 key를, $API_KEY 부분에는 Xcode Cloud의 Environment에 추가한 variable 이름을 넣으면 된다.

 

4) plutil -p ./{plist 폴더}/API.plist

- 해당 위치의 API.plist 파일의 내용을 -p. 출력하는 것이다.

- replace가 잘 이뤄졌는지 확인하기 위해 쓴다.

 

5) echo "Stage: PRE-Xcode Build End"

- 1)과 마찬가지로 단계를 확인하기 위한 문구. 없어도 무방.

 

6) exit 0

- sh파일 실행 종료

 

3. ci_pre_xcodebuild.sh 권한 설정

- 이제 파일이 실행될 수 있도록 권한을 설정해줘야 한다.

Xcode에서 sh파일 우클릭 -> Show in Finder를 클릭해서 위치로 간 다음, 해당 경로를 터미널에서 열기로 열어준다.

 

그리고 다음의 구문 입력

chmod +x ci_pre_xcodebuild.sh

 

이를 통해 셸 스크립트를 실행 파일로 만든다.

 

위의 명령은 +x(execute)로, 실행 권한을 주는 것이다. 이 또한 위 공식문서 링크에서 확인할 수 있다.

 

https://developer.apple.com/documentation/xcode/writing-custom-build-scripts

 

4. GitHub Push

- 이제 파일 생성, 수정, 권한 설정까지 끝났으니 GitHub에 Push 해준다.

 

- Xcode Cloud는 지정한 브랜치를 가져와서 빌드를 하기 때문에 브랜치에 파일이 있어야 하기 때문이다.
   (여기서도 몇 번 헤맸다. 공식문서를 꼭 보자...)

 

- Push 먼저 하고 권한 설정하면 아래와 같은 오류를 보게 될 것이다.

 

5. Xcode Cloud Build 실행

- 이제 빌드를 실행해 보면 다음의 결과를 얻을 수 있다.

 

 

- API.plist에 API_KEY만 key로 추가하고 value를 주지 않았기 때문에 실패를 했을 땐 "API_KEY" => "" 로만 나왔었다.

  이제는 sh파일이 성공적으로 실행되었고, replace가 제대로 동작했기 때문에 Environment Variables에 설정한 값이 API_KEY에

  들어갔음을 볼 수 있다(Variables 등록 시 Secret을 체크했기 때문에 마스킹 처리가 되어있음).

 

끝...

(24. 03. 23. 20:40 추가)

인 줄 알았는데?

 

문제 해결에 사라진 꿀같은 토요일 10시간

 

문제가 발생했다.

 

심사를 위해 제출한 앱에서 콘텐츠가 로드가 안된다고 한다.

 

진짜 API값 주입 과정, 빌드 과정 전체를 다 봐도 도저히 실마리를 찾을 수 없어 9시간이 날아간 끝에서야 의문이 들었다.

 

'Xcode Cloud에 환경변수를 설정해 줬는데, TestFlight에 올릴 때는 Xcode의 기본 Archive 기능으로 빌드하잖아. 그러면 영향을 안 주는 거 아냐?'

(Archive 기능으로 생성된 앱 번들과 Xcode Cloud의 build Artifacts의 Archive 앱 번들을 둘 다 열어본 결과 이는 사실로 판명..)

넌 평소에 TestFlight을 소중히 여기지 않았지

 

애초에 TestFlight에서 테스트를 해봤으면 나왔을 문제였는데.. 참.. 어쨌든 이렇게 알아가면 되는 거니까.

 

그렇다면 이제 Xcode Cloud로 빌드한 것을 어떻게 TestFlight에 넘겨 테스트를 하고 심사에 제출할 수 있느냐가 문제일 것이다.

 

여기서부터는 재삽질의 과정 대신 상기한 5번 과정 다음부터 차례로 정리해 보겠다.

 

6. App Store Connect Xcode Cloud 설정하기

Xcode Cloud를 사용하게 되면 이름을 따로 지정하지 않은 이상 default라는 워크플로가 하나 생길 것이다.

 

워크플로 구성은 기본 저장소, 환경, 시작 조건 등이 있는데, 기본 저장소나 브랜치는 처음 클라우드를 설정할 때 연결할 것이므로 이미 채워져 있을 것이다.

 

환경변수 역시 Xcode에서 Cloud 설정하면서 1번 과정을 했기 때문에 '1개의 변수'라고 쓰여 있을 것이다.

 

맨 아래 작업 탭에 아카이브 - iOS를 보면 배포 준비라는 항목이 있다.

 

 

여기서 '없음'이라고 되어 있다면 변경을 해줘야 한다(이걸 안 해서 이 고통을...).

(1번 과정 직전 Cloud를 처음 시작할 때 이걸 선택해 줬다면 상관없다. 본인은 없음을 선택했기 때문에 그 후폭풍을 맞는 것..)

 

다만 워크플로는 브랜치 변경 사항이 있다면 빌드를 자동으로 하기 때문에 빌드를 할 때마다 배포용으로 아카이빙을 할 필요는 없지 않을까?

 

설명에서도 다음과 같이 말한다.

 

 

그래서 워크플로를 하나 더 만들었다.

 

배포용 워크플로는 App Store Connect로 설정해서 여기서 빌드하는 것은 TestFlight 및 앱 심사에 사용할 목적으로 쓰고, TestFlight 워크플로는 TestFlight으로 설정해서 변경점이 있을 때 Test용으로 쓰기로 했다.

 

7. TestFlight에서 내부 테스팅 돌려보기

나중에 분리한거라 두 워크플로 모두 main에 연결되어 있다. 테스트용엔 다른 브랜치를 연결하자.

 

Xcode Cloud 탭에서 워크플로를 선택하고 Start Build를 하거나, 테스트용 워크플로에 연결한 브랜치에 변경점이 생기면 빌드를 할 것이다.

 

App Store Connect 페이지의 Xcode Cloud탭에서 그 과정이 끝나면 자동으로 TestFlight 탭에 항목이 생기게 된다.

 

28번의 빌드 삽질.. 아까운 Xcode Cloud 사용시간..

 

해당 워크플로는 6번 설정에서 TestFlight(내부 테스트 전용)을 선택했기 때문에 빌드번호 아래에 내부가 적혀있음을 볼 수 있다.

(내부 테스트 전용 빌드는 심사에 제출하지 못한다)

 

이미지에는 테스트 중이라고 나와있는데, 처음에는 수출 규정 설정이 쓰여있을 것이다. 해당하는 항목에 체크하고 오른쪽 그룹에서 내부 테스팅 그룹을 선택해 주면 TestFlight 앱에서 새 빌드가 사용 가능하다고 푸시 알림이 올 것이다.

 

다운로드 받아서 환경변수로 API키 값이 잘 전달되어 콘텐츠가 정상적으로 불러와지는지, 원하는 기능이 잘 작동하는지 확인해 보자.

 

8. 심사 제출

7번 과정에서 앱이 정상적으로 작동하는 것을 확인했으면 main 혹은 출시용 브랜치에 변경점을 적용하자.

 

그러면 자동으로 빌드가 될 것이고 테스트용 워크플로때와 마찬가지로 TestFlight에 빌드가 올라올 것이다.

 

그 사이 변경점은 하나도 없는데 '빌드 번호 이게 맞나?' 하다가 늘어나버린 숫자..

 

해당 빌드도 혹시 모르니 내부 테스팅 한 번 해보고 이상이 없으면 배포 탭에서 빌드 선택 후 심사에 제출하면 된다.

 

 

진짜 끝.

많은 시간이 들어가고, 많은 삽질을 했고 참 많이 힘들었지만 이 과정을 통해서 Xcode Cloud, TestFlight, 배포 과정에 대해 좀 더 알게 되었고 특히나 API Key 같은 민감한 정보를 깃 저장소에 남기지 않고 앱을 배포할 수 있는 방법을 알게 되었다는 점에서 큰 경험 얻었다고 생각한다.

(한 번 해봤으니 다음엔 더 능숙하게)

 

아마 이 주제로 검색하면 나오는 것도 한정적이고 내용도 각각 다를 텐데.. 이 글 보시고 따라 하면 무난히 성공하시지 않을까 한다.

'Apple Developer > iOS(Swift)' 카테고리의 다른 글

[Xcode] no scheme 문제 해결  (0) 2024.02.18
[들꽃] 개인정보 처리방침  (0) 2023.11.30
Swift ARC (WWDC2021)  (0) 2023.08.08
Render Loop, Life Cycle  (0) 2023.07.21
SOLID 원칙(객체 지향 설계)  (0) 2023.07.20