Xcode Cloud 최대한 활용하기

♪ ♪ 안녕하세요, 저는 Adam입니다 Developer Experience Team 매니저입니다 전 Xcode Cloud Team 엔지니어 Sasan입니다 이 세션에서는 기존 워크플로를 검토하고 완전히 새로워진 Xcode Cloud 사용량 대시보드를 살펴보면서 어떻게 Xcode Cloud를 최대한 활용할 수 있는지 보여드릴게요 그 다음 기존 프로젝트 사용량을 보고 배운 내용을 바탕으로 더 나은 최적화를 위해 어떻게 사용할지를 살펴보고 프로젝트의 새 Watch OS App 버전 개발을 시작하는 방법도 살펴보겠습니다 먼저 Xcode Cloud의 개요를 빨리 짚고 넘어갈게요 Apple은 WWDC 2021에서 Apple 개발자를 위해 특별히 설계된 지속적 통합 및 전달 서비스이자 Xcode에 내장된 Xcode Cloud를 발표했습니다 Xcode Cloud는 지속적 통합 및 전달 그리고 코드 개발 및 유지 관리에 도움이 되는 표준 소프트웨어 개발 방식을 제안하고 테스터와 사용자 모두에 앱을 제공합니다 Xcode Cloud는 고품질 앱의 개발과 제공을 가속하고 이는 앱을 빌드하고, 자동화된 테스트를 병렬로 실행하고 테스터에게 앱을 제공하고, 사용자 피드백을 확인하고 관리하는 데 도움이 되는 클라우드 기반 도구를 통해 이루어지며 동시에 사용자 개인 정보도 보호합니다 Xcode Cloud를 처음 설정하는 자세한 방법은 WWDC 2021의 'Xcode Cloud를 소개합니다'에서 확인하세요 홀리와 제프가 첫 워크플로 설정을 자세히 안내해 드릴 겁니다 이제 기존의 워크플로를 살펴보고 Xcode Cloud의 Food Truck 앱을 빌드해 보겠습니다 이건 App Store Connect의 Xcode Cloud 대시보드로 Food Truck 프로젝트의 최근 빌드에 관한 개요를 담고 있어요 최근 컴패니언 watchOS 앱을 만들기로 했는데 이를 통해 푸드 트럭 운영자가 새 주문이 들어올 때마다 전화를 받을 필요 없이 시계를 통해 빠르게 주문을 수락할 수 있죠 Xcode Cloud의 새 watchOS 앱을 빌드하기 전에 현재 워크플로와 프로젝트를 완전히 최적화하여 가능한 빠른 빌드 및 테스트 결과를 얻고자 했습니다 여기에 아마 시간과 자원을 아낄 수 있는 몇몇 방법이 있을 텐데요

어떤 부분의 최적화를 시작하면 좋을지를 잘 이해하기 위해 우선 빌드 세부 정보 개요를 살펴보겠습니다 오전 9시 15분에 빌드를 시작했고 결과를 얻는 데 14분이 걸렸습니다 그리고 사용한 시간은 이 경우 32분으로 확인됐죠 이건 14분짜리 빌드 작업이 모두 완료되는 데 걸린 총 시간입니다 사용량 다음으로 보이는 것은 이 빌드의 작업 분포를 볼 수 있는 옵션인데요

각 작업은 개별 사용과 함께 나눠지며 하단에는 총 32분이 표시됩니다 이 사용량 분포는 최적화가 가능한 장소가 어딜 지에 관한 아이디어를 주기도 합니다 하지만 그전에 어떻게 Xcode Cloud가 이런 작업을 수행하는지 그리고 빌드 시간과 사용량과의 차이는 무엇인지 자세히 한 번 살펴볼게요

각 빌드는 워크플로 설정을 기반으로 일련의 작업으로 나뉩니다 여기서는 Xcode Cloud가 각 작업을 Analyze, Archive, Build, 그리고 Test와 같은 여러 병렬 작업으로 나누는 것을 볼 수 있어요 이런 작업은 병렬로 이루어지기 때문에 빌드 시간은 가장 긴 실행 작업과 동일합니다 이건 완료까지 14분이 걸린 워크플로에서 구성한 테스트입니다 사용량은 순서대로 관찰한 각 작업을 계산하여 빌드의 총 컴퓨팅 사용량을 알 수 있고 이 경우 32분이 되겠네요 이렇게 Xcode Cloud가 빌드 시간과 빌드 사용량을 계산합니다

그럼 이제 App Store Connect의 Xcode Cloud 사용량 대시보드를 살펴볼게요 가장 상단에는 총 백분율을 포함하여 Truck to Table Team의 월 주기를 시작으로 사용량 개요가 나와 있어요 그리고 분 단위로 표시된 총사용량과 함께 팀의 현재 주기에서 사용 가능한 잔여 컴퓨팅도 확인할 수 있죠

이 밑에는 지난 30일 동안의 증가 또는 감소 비율과 함께 생성된 빌드와 전체 사용량으로 나뉘는 팀의 사용량 추세가 나와 있습니다 다른 기간의 사용량을 확인하려면 추세 섹션의 오른쪽 상단 모서리에 있는 기간을 변경하면 됩니다

페이지 하단으로 좀 내려가면 위에서 선택한 기간 중 현재 Xcode Cloud를 사용하고 있는 각 제품의 사용량을 확인할 수 있어요 좋아요, 이제 Food Truck을 선택하여 총 사용량을 확인할게요

여기서 팀 보기에서 본 것과 같은 추세를 볼 수 있지만 지금은 Food Truck 프로젝트에 국한되어 있어요 하단으로 더 내려가면 각 워크플로의 사용량 통계를 볼 수 있습니다 우선 Release 워크플로에서 몇몇 최적화를 시작할 최적의 장소를 발견할 수 있는데요 이제 Sasan에게 차례를 넘겨 빌드 세부 정보와 컴퓨팅 사용량을 살펴본 다음 프로젝트를 최적화할 몇 가지 방법을 알아볼게요 어떻게 하는 건지 보여줘요, Sasan 고마워요, Adam 우선 Xcode Cloud 사용의 몇 가지 모범 사례를 다뤄보기 위해 Food Truck 프로젝트를 살펴볼게요 이렇게 하면 새 watchOS 앱에서 빨리 반복을 시작할 수 있어요 워크플로는 Start Conditions를 통해 빌드의 시작을 결정합니다 Start Conditions를 구성하는 것이 중요하며 이게 구성되어야 워크플로용 변경에만 대해 빌드가 시작됩니다 이제 Food Truck 프로젝트의 Release 워크플로에 이 사례를 어떻게 적용할지 알아볼게요 하지만 먼저 'Xcode Cloud 워크플로 알아보기'에서 자세한 내용을 확인해보세요

이건 Adam이 Xcode에서 보여준 것과 동일한 빌드인데요 우선 편집기 창에서 Release 워크플로를 열어 볼게요

Navigation Panel에서 Workflow를 마우스 오른쪽 클릭하고 Edit Workflow를 선택합니다

편집기 창에서는 Start Conditions 는 물론 Workflow를 구성하는 모든 구성 섹션을 볼 수 있습니다 가끔 예정된 빌드에는 새로운 변화가 없다는 것을 알아채곤 하는데요 이 부분을 해결하기 위해 분기 변화에 새 시작 조건을 추가하여 예정된 시작 조건을 대체하도록 하겠습니다 이렇게 하면 중복 커밋이 생기지 않을 거예요 Plus 버튼의 I에서 Branch Changes를 선택합니다

이제 예정된 시작 조건을 삭제하려면 해당 조건을 선택하고 휴지통 아이콘을 클릭합니다

Branch Changes Start Condition은 새 커밋이 원격 브랜치를 푸시할 때마다 실행됩니다 기본적으로 Source Branch는 Any Branch로 구성되며 이는 repo의 브랜치에 변경 사항이 생기면 이 워크플로가 빌드를 시작한다는 것을 의미해요 release 워크플로가 완전히 구성되었으므로 이제 release 브랜치에서만 빌드를 시작하도록 제한하고 싶어요

Custom Branches를 클릭하면 사용자 지정 브랜치를 지정해야 한다는 것을 바로 알 수 있죠

Plus 버튼을 클릭하여 브랜치 이름을 입력합니다

편집기로 정확한 브랜치 이름이나 접두사를 선택할 수 있어요 이 경우 여러 release 브랜치가 있기 때문에 저는 'release'로 시작하는 브랜치를 선택할게요

그리고 release 브랜치에서 빌드를 시작할 수 있는 파일과 폴더를 지정합니다 전 문서 폴더가 수정될 때는 빌드가 되지 않았으면 합니다 이 폴더에는 Apple의 개발 문서만 있으니 그냥 넘어가도록 할게요 Files 및 Folders 옵션에서는 Custom Conditions를 선택합니다

Start a Build 드롭다운에서 Don't start a build를 선택합니다

그리고 Plus 버튼을 클릭하여 새 조건을 추가합니다

Any Folder를 선택하고 Choose를 선택하여 제외할 폴더를 지정합니다

마지막으로 파일 선택기를 열어 문서 폴더를 선택하고 Open을 클릭합니다

마지막으로 변경 사항을 유지하기 위해 Save를 클릭합니다

이제 Start Condition을 보다 선택적으로 구성하였으니 release 접두사가 있는 브랜치만 제한하여 문서 폴더의 변경 사항을 무시할 수 있어요 또한 워크플로는 빌드 실행 방법을 사전에 정의된 Actions를 사용해서 정의합니다 Actions로 변경 사항을 분석 보관, 빌드 및 테스트할 수 있어요 테스트의 중요 구성 요소 중 하나는 테스트 대상 선택입니다 결과를 빨리 전달하기 위해 테스트 제품이 빌드되는 즉시 각 대상은 병렬로 실행됩니다

테스트를 위해 간단한 시뮬레이터 대상 세트를 선택했는지 확인도 해야 합니다 이건 빌드를 빨리 진행하는 것 외에도 유사한 장치에서의 실패와 같은

테스트 노이즈를 줄이는 데 도움이 되죠

Xcode Cloud는 추천된 대상을 위한 에일리어스를 제공합니다 이건 화면 크기의 단면에 대한 선별된 시뮬레이터 목록입니다

이제 Release 워크플로를 다시 방문해 iOS 테스트 작업의 적절한 시뮬레이터 대상 세트를 어떻게 선택하는지 볼게요 Test iOS 작업을 선택하면 다양한 테스트 대상이 선택된 것을 볼 수 있어요 테스트 대상을 제거하려면 하나씩 선택하여 마이너스 버튼을 클릭합니다 그리고 마지막 아이템에서 드롭다운 메뉴를 클릭한 다음 Recommended iPhones를 선택합니다

변경 사항을 저장하기 위해 Save를 클릭할게요

이제 테스트 대상이 생겼으니 만약 회귀를 하게 된다면 분명한 시그널을 제공할 수 있을 거예요

앞서 논의했듯이 Xcode Cloud는 리포지터리에 새 변경 사항을 푸시할 때 워크플로를 실행합니다 때로는 커밋되는 변경 사항의 타입에 따라 CI에서 빌드하는 과정을 건너뛸 수도 있습니다 이런 기능은 이미 추가했었죠 이제 Xcode를 한번 살펴볼게요

커밋 메시지의 끝에 'ci skip'을 추가하면 Xcode Cloud에서 커밋을 건너뛸 수 있습니다 이제 원격으로 푸시하면 Xcode Cloud는 이 이벤트를 무시할 겁니다

반드시 여기 보이는 ci skip 태그와 같은 형식을 써야 합니다

각 작업에서 사용자 지정 스크립트는 여러 포인트에서 실행됩니다 사용하지 않는 종속성을 정리하고 신뢰할 수 없는 API 요청을 계속 재시도하면 빠르고 일관된 빌드 완료가 가능합니다 사용자 정의 스크립트와 다른 고급 사용자 정의의 자세한 내용은 '고급 Xcode Cloud 워크플로 사용자 정의하기'를 참고하세요

테스트를 위해 부실하고 신뢰할 수 없는 테스트는 빨리 수정해야 합니다 부실 테스트 실패 시, instinct는 바로 빌드를 재시도하죠 테스트 스위트의 신뢰도에 따라 많이 재시도된 빌드가 생길 수도 있습니다 신뢰도 있는 테스트를 위해 더 많은 시간을 들어야 해요

효과적으로 이를 작업하는 자세한 방법은 'Xcode Cloud를 위한 빠르고 신뢰도 높은 테스트 작성'을 참고하세요 지금까지 몇몇 모범 사례를 살펴보고 이를 Food Truck 프로젝트에 적용해 봤습니다 이제 이전 빌드와 업데이트된 워크플로를 비교하여 이런 변경 사항이 어떤 영향을 미쳤는지 살펴볼게요 이건 모범 사례를 적용한 빌드입니다 Adam이 보여드린 이전 빌드와 비교하면 지속 시간은 1분 감소했지만 사용량은 4분 감소했어요 전반적으로 개선된 부분이 조금 있는 것 같네요

영향력에 대한 더 나은 이해를 위해 사용량 대시보드로 돌아가 보겠습니다

하나의 빌드에 미치는 영향을 바로 확인하기 어려울 수 있어 다른 워크플로인 Integration Workflow에 모범 사례를 적용해 보겠습니다 모범 사례가 적용된 빌드를 계속 실행했는데요 사용량이 줄고 있기 때문에 변경 사항이 효과가 있다고 볼 수 있겠네요

이건 이제 watchOS 앱 개발을 위해 워크플로를 추가하고 더 많은 빌드가 가능하다는 것을 의미합니다

사용량 대시보드를 사용해 기존 프로젝트나 워크플로에 동일한 모범 사례를 계속 적용하여 Xcode Cloud를 최대한 활용할 수 있을 거예요 큰 규모의 팀을 위한 Xcode Cloud 관리 방법이 궁금하다면 '팀을 위한 Xcode Cloud 심층 분석'을 참고하세요 본 세션이 도움이 되었길 바랍니다 시청해 주셔서 감사합니다

♪ ♪