Deep dive into Xcode Cloud for teams

안녕하세요, 저는 Xcode Cloud 팀의 엔지니어 John입니다 그리고 저는 Xcode Cloud 팀의 디자이너 Jo Lynn입니다 오늘은 팀의 규모에 상관없이 Xcode Cloud를 도입하면 사용할 수 있는 매우 유용한 몇 가지 기능을 살펴보겠습니다 전 Xcode Cloud를 팀에 도입할 경우 도움이 되는 다른 기능과 모범 사례를 알려드릴게요 오늘 세션에서는 다른 세션에서도 다루는 주제 몇 가지도 자세히 살펴볼 예정입니다 혹시 웹훅이나 기타 고급 워크플로를 자세히 알고 싶다면 '고급 Xcode Cloud 워크플로 사용자 지정하기' 세션을 참고하세요 이 세션에서는 매일 사용하는 Xcode Cloud의 기본 도구 및 기술을 통합하는 방법과 코드 종속성을 쉽게 관리하는 방법을 살펴보고 앱을 지속적이고 효과적으로 빌드, 테스트, 배포하기 위한 워크플로를 설정하는 데 도움이 되는 Xcode Could의 모범 사례를 살펴보겠습니다

이제 시작해 볼게요 Xcode Cloud를 기존 도구에 통합하는 방법은 여러 개가 있습니다 웹훅을 사용하면 지원하는 도구 및 서비스와 쉽게 통합할 수 있어요 App Store Connect에 웹훅을 연결할 수 있는데 Xcode Cloud에 웹훅을 보낼 URL을 지정하면 됩니다 그렇게 하면 해당 웹훅이 바로바로 들어올 거예요

더불어 API를 사용하면 대시보드를 쉽게 생성하거나 빌드 산출물을 추출하거나 오늘 다룰 예시처럼 기존의 소프트웨어에 빌드 정보를 통합함으로써 빌드에 많은 가시성을 사용할 수 있어요

지금까지 푸드 트럭 앱의 새 기능을 추가해왔지만 반면 새 버그도 발견하고 이젠 앱을 함께 만드는 팀이 생겨서 누가 무슨 일을 하고 있는지 알기가 어려워졌어요

이 문제를 해결하기 위해 이슈 트래커를 사용하여 앱에서 진행 중인 모든 작업을 추적하기로 했습니다 만약 이슈 트래커를 사용한다면 아마 이런 보기를 보게 될 거예요 이슈 트래커를 사용하는 일반적인 워크플로는 티켓을 생성하고 디자이너와 개발자가 그 티켓을 작업하며 마지막으로 기능이나 버그가 완료되면 그 작업을 종료합니다 실제 빌드 정도가 이슈 트래커에 표시되면 모든 상황을 이해하는 데 큰 도움이 됩니다 어떻게 하는 건지 살펴볼게요 우리의 계획은 아주 간단한 Swift On Server-based 서비스를 만드는 것인데요 이건 이슈 트래커를 Xcode Cloud와 통합하는 데 필요한 모든 작업을 처리합니다 Vapor 웹 프레임워크를 사용하면 개발 속도를 높이고 웹훅 핸들링 코드 작성에 집중할 수 있어요 기본적인 플로우는 다음과 같습니다 먼저 웹훅이 Xcode Cloud에서 우리 서버로 넘어오고 웹훅을 읽은 다음 커미터에서 작성한 커밋 메시지에 트래커에 있는 이슈를 가리키는 특정 문자열이 포함되어 있는지를 확인합니다 만약 있다면 Xcode Cloud API를 눌러 빌드에 대한 추가 정보를 모아야 해요 그리고 관심 있는 정보를 담은 이슈 트래커에 게시할 코멘트를 구성합니다

그리고 이슈 트래커에서 API를 호출하여 이슈와 관련된 메시지를 저장합니다 먼저 Xcode Cloud API 문서를 살펴볼게요 모든 Xcode Cloud API는 App Store Connect API에 있습니다 App Store Connect API를 위한 인증 토큰을 이미 설정해 놓았다면 Xcode Cloud 데이터에 엑세스하기 위한 준비가 모두 끝났습니다 Build Runs 컬렉션을 열면 빌드와 상호 작용하는 몇몇 엔드포인트가 있어요 빌드를 생성하거나 빌드를 취소하고 특정 빌드에 관한 더 많은 정보를 얻기 위해 엔드포인트를 호출합니다 예를 들어 만약 빌드 상태를 보여주는 대시보드를 빌드하려면 Ci_Build_Runs 엔드포인트만 호출하면 되죠 다음으로 문서의 Artifacts 컬렉션을 살펴볼게요 워크플로를 위해서는 빌드 산출물을 Xcode Cloud 외부에 두고 API가 필요한 모든 조건을 갖추고 있어야 해요 우선 빌드 작업 엔드포인트에서 산출물 ID를 가져와서 주어진 작업이 생산하는 모든 산출물을 반환합니다 그 다음 downloadUrl 속성의 산출물을 다운로드하기 위한 URL을 얻기 위해 ci_artifact를 호출합니다 App Store Connect 문서에서 openAPI 스펙을 다운로드하고 API를 위한 클라이언트 생성에 필요한 게 무엇인지 살펴볼게요

이제 클라이언트 코드를 생성할 새 디렉터리를 생성하겠습니다 우선 이 xcodecloud-client를 호출할게요 이제 제너레이터의 명령줄 도구를 다운로드해야 합니다 이 작업을 할 수 있는 다양한 방법은 openAPI 웹사이트에 있고 이 세션의 경우 미리 설정을 해뒀습니다 이제 app_store_connect_API에서 가져온 openAPI 스펙을 우리 디렉터리에 복사할게요 좋네요, 이제 openAPI 제너레이터를 호출하여 API를 위한 스위프트 클라이언트를 생성하도록 하겠습니다

제너레이터가 실행되는 동안 이게 무슨 역할을 하는지 잠깐 말씀드릴게요 openAPI 사양은 API를 구성하는 모든 경로와 모델에 대한 정보로 만들어졌습니다 제너레이터는 각 API 경로를 통과하며 Swift 코드를 생성하고 이는 강력한 타입의 스위프트 객체를 통해 특정 경로와 통신할 수 있죠 대부분 이건 JSON 인코딩이나 디코딩이 필요 없다는 것을 의미해요 좋네요 이제 제너레이터가 완료되었으니 생성된 파일을 잠깐 살펴볼게요 다행히 클라이언트 코드가 Swift 패키지군요 이렇게 하면 업데이트할 웹훅 서버에 이슈 트래커를 쉽게 넣을 수 있어요 이제 새 git 리포지토리에 코드를 커밋하고 이걸 Swift 패키지로 참조할게요 이제 API와 통신하기 위한 준비가 모두 끝났으니 웹훅을 설정할게요 빌드가 완료될 때마다 서버에게 이를 알리는 웹훅을 App Store Connect에 등록합니다 이렇게 하려면 App Store Connect에서 제품으로 이동한 다음 설정으로 가서 웹훅으로 이동합니다

그리고 서버에 URL을 붙여 넣습니다 이렇게 하면 Xcode Cloud가 웹훅을 어디로 보낼지 알 겁니다 웹훅이 설정되면 이제 남은 것은 이를 프로세스 할 코드를 작성하는 겁니다, 이제 시작해 볼게요 먼저 웹훅에서 우리가 원하는 필드와 일치하는 구조체를 정의해야 합니다 웹훅은 수행되는 각 작업은 물론 실행되는 특정 빌드의 정보도 담고 있죠 그러니 이 내용들을 웹훅 페이로드 구조체에 유지하도록 할게요

다음으로 함수로 들어오는 웹훅을 바르게 라우트하는 Vapour가 있는 코드를 작성해야 합니다 그리고 웹훅 경로에 대한 게시 요청을 실행하는 함수를 정의하죠 강력한 타입의 Swift 객체로 들어오는 JSON 페이로드를 변환하기 위해 우리가 할 일은 이 함수 안에서 이걸 디코딩하여 코드를 추가하는 거예요

좋습니다, 이제 남은 것은 Xcode Cloud API를 호출해 방금 완료한 빌드 정보를 가져와 이슈 트래커 페이지에 포함시키는 겁니다 웹훅 페이로드는 방금 실행한 빌드에 대한 많은 정보와 성공하거나 실패한 작업에 대한 정보도 가지고 있어요 우선 여기까지만 하고 다음 단계로 넘어가 볼게요 아마 각 작업에 어떤 문제가 있는지에 대한 정보를 포함하면 좋을 것 같네요

CiBuildActionsAPI에 확장 함수를 작성하면 원하는 특정 작업의 이슈를 쉽게 반환할 수 있어요

이 확장에서는 매개변수로서 빌드 작업 ID가 있는 함수를 작성하고 특정 작업에서 발견된 모든 이슈를 반환합니다

이미 이 프로젝트에는 있지만 다른 코드에도 적용해볼게요

빌드가 완료된 경우에만 웹훅 핸들러가 실행되도록 해야 하니 이 부분을 꼭 지키도록 하세요 다음으로 코멘트 문자열 작업을 시작해 볼게요 문자열 작성뿐만 아니라 빌드 번호, 커밋 해시도 있으면 좋겠어요

이제 각 작업을 모두 살펴보고 각 작업의 이슈를 알아내기 위한 확장 함수를 호출해 보겠습니다 그리고 이걸 다 이슈 트래커에 전달하도록 할게요

이 모든 정보를 기반으로 이슈 트래커를 빌드에 맞는 최신 상태로 만들 수 있습니다 이제 다 됐습니다 우선 웹훅을 위해 Xcode Cloud에 제공한 URL의 서버 코드를 호스트하려면 이슈 트래커의 Xcode Cloud 빌드 정보를 찾아봐야 합니다

이제 지금까지 배운 내용을 빠르게 훑어볼게요 Xcode Cloud에는 기존의 개발 워크플로와의 긴밀한 통합을 위한 API가 있고 웹훅과 함께 해당 API를 사용하면 모든 내용을 파악하고 기존의 도구와 Xcode Cloud의 기술을 통합할 수 있어요 이어서 Jo와 함께 모범 사례와 다른 기능을 살펴보겠습니다 고마워요, John Xcode Cloud는 API와 프레임워크를 생성하는 데 쓰는 Apple 개발자 도구 및 서비스와 통합되도록 설계되었어요 하지만 여러분의 Xcode 프로젝트는 코드를 컴파일할 추가적인 종속성이나 외부 도구가 필요할 수도 있습니다 Xcode Cloud는 Swift Package Manager와 함께 쓰면 좋아요 왜냐하면 패키지의 리포지터리가 공개적으로 액세스할 수 있는 경우에도 추가적인 구성 없이 Swift 패키지 종속성을 지원하거든요 Cocoapods나 Carthage 같은 제3자 종속성 매니저와도 함께 사용할 수 있지만 사용자 정의 빌드 스크립트를 사용해야 한다는 특징이 있죠 Xcode Cloud용 종속성을 만드는 방법은 Xcode 문서를 참고하시기 바랍니다

일단 Swift 패키지를 추가하고 변경 사항을 푸시하여 워크플로를 시작하면 Report Navigator의 클라우드 탭에서 최신 빌드 상태를 확인할 수 있어요

Logs를 선택하면 자세한 빌드 로그를 볼 수 있습니다

이제 Xcode Cloud가 자동으로 종속성을 해결했네요 Xcode Cloud가 첫 빌드를 성공적으로 완료하면 지속적 통합 및 전달 방식을 개선하기 위한 다음 단계를 계획해야 하죠 이렇게 하면 앱이나 프레임워크가 항상 전달 가능한 상태인지를 확인할 수 있어요 이번 섹션에서는 정적 코드 분석을 위해 Xcode Cloud와 SwiftLint를 함께 쓰는 방법과 워크플로를 제한적으로 편집하는 방법 그리고 여러 시작 조건 구성의 가치를 살펴보겠습니다 SwiftLint는 오픈 소스 린트 도구로 Swift 커뮤니티에서 일반적으로 사용하는 스타일 가이드와 규칙을 적용합니다 이를 통해 코드 품질을 개선하고 부정 사례를 예방하기 위한 정적 코드 분석을 수행하죠 특히 SiwftLint는 큰 규모의 팀과 작업할 때 팀의 코드베이스를 유지하는 좋은 방법이에요 지금부터 사용자 정의 빌드 스크립트를 사용해 Xcode Cloud와 SwiftLint를 어떻게 통합하는지 보여드릴게요 우선 팀의 주요 리포지터리에서 소스 코드를 복제한 다음 Xcode Cloud가 SwiftLint 도구를 실행하게 합니다 Project 내비게이터 안의 Food Truck 프로젝트 속 ci_scripts 폴더에 이미 post_clone 스크립트를 추가헸어요

Xcode Cloud는 Homebrew와 같은 환경을 만들고 이걸 사용해 여기에 SwiftLint를 설치합니다

이 줄에서 SwiftLint를 실행하고 있어요 한 가지 기억할 점은 스크립트가 ci_scripts 디렉터리에서 실행되기 때문에, SwiftLint가 우리의 리포지터리를 가리키는 ci_workspace 환경 변수 내에서 실행하게끔 해야 합니다

이제 코드 분석의 결과를 같이 봅시다 SwiftLint가 꽤 많은 위반 사항을 발견한 것 같네요 그중 15개는 심각해 보입니다 도구를 통합하는 게 처음이라 먼저 이 워크플로를 일시적으로 비활성화하겠습니다 그래야 다른 팀원들과 논의하여 코딩 스타일과 규칙에 대해 합의하고 해결하고 싶은 이슈를 팀과 결정할 수 있어요 Manage Workflows 메뉴에서 Xcode 워크플로의 비활성화가 가능합니다 이렇게 하면 시작 조건이 멈추고 매뉴얼 빌드만 작동합니다

이제 정적 코드 분석 워크플로가 비활성화되었으니 해결하려는 문제에 더 집중할 수 있어요 그런 다음 돌아와 이 워크플로를 작동해 볼게요 팀이 빠르게 커지고 있고 워크플로 구성에 대해 올바른 선택을 하고 싶어요 제가 팀의 워크플로를 유지 관리하는 사람이니 팀 멤버들이 워크플로에 의도치 않은 변화를 가져오게 둘 순 없죠 되돌리는 데 많은 시간이 걸릴 거예요 의도치 않은 변화를 막기 위해서는 워크플로를 편집하는 사람을 제한해야 하죠 워크플로의 컨텍스트 메뉴에서 Restrict Editing을 선택합니다 팀원 누구나 워크플로를 실행할 수 있지만 관리자, 계정 소유자 그리고 앱 매니저만 제한할 수 있기 때문에 이들만 수정이 가능합니다

편집이 제한된 워크플로에는 '키' 기호가 있을 거예요 이건 잠겨있기 때문에 여러분이나 다른 관리자 사용자만 편집할 수 있다는 의미입니다

'잠금' 기호가 있다면 관리자에 의해 잠겨있다는 의미이고 편집이 불가합니다 이 기능은 복잡한 워크플로 액세스를 쉽게 관리하고 특히 큰 규모의 팀에 유용하죠 워크플로를 중지하거나 잠그는 쉬운 방법을 배웠으니 이제 워크플로 관리와 유지에 관한 얘기를 나눠볼게요

풀 요청이나 브랜치를 병합할 때마다 작업을 모으고 같은 테스트를 실행하기 위한 최고의 방법은 여러 시작 조건을 사용하는 거예요 이렇게 하면 워크플로 관리가 개선됩니다 왜냐하면 생성하고 관리할 워크플로 개수를 줄일 수 있거든요 이 예시로 설명을 드리자면 다음과 같은 조건에서 빌드를 한다고 가정할게요 메인 브랜치나 release 브랜치에 변경 사항이 있거나 메인 브랜치에 예약된 빌드가 있다면 내부 테스트를 위한 TestFlight 배포뿐만 아니라 동일한 아카이브와 테스트 작업 세트를 실행합니다 세 개의 워크플로를 생성하는 대신 이들을 동기화하여 유지하고 관리하여 한 번에 모든 시작 조건을 정하는 단일 워크플로를 만들 수 있죠 그럼 특히 유지 관리할 워크플로가 많은 팀의 관리 효율성이 개선됩니다 Xcode의 시작 조건을 구성하는 것은 쉽습니다 워크플로 편집기에서 플러스 버튼 메뉴 중 시작 조건 타입을 고르면 되죠

App Store Connect의 Xcode Cloud는 모든 기능을 갖춘 웹 기반 경험을 제공합니다 비활성화와 잠금부터 여러 시작 조건 설정까지 워크플로를 구성하기 위해 제가 Xcode에서 한 모든 작업은 AppStoreConnect에서도 가능합니다 Xcode Cloud는 Xcode에 내장된 강력한 지속적 통합 및 전달 서비스로 어떤 규모의 개발팀들도 지원할 수 있으며 기존 도구 및 프로세스와 쉽게 통합하여 사용자에게 고품질 앱을 제공합니다 Xcode Cloud 베타 참가자분들의 피드백에 감사드리며 앞으로도 더 많은 의견을 전달해 주시길 바랍니다 이 기능을 활용하여 팀의 지속적 통합 및 전달 방법 개선에 도움이 되길 바랍니다 시청해 주셔서 감사하며 유익한 WWDC가 되길 바랍니다