Xcode Cloud에서의 실용적인 작업 흐름 만들기

♪ ♪

안녕하세요 저는 Romain입니다 Xcode Cloud 엔지니어고요 Xcode Cloud는 강력한 툴입니다 팀 개발 프로세스에 바로 통합될 수 있을만큼 유연하죠 생산성도 향상시키고 소비자들에게 더 나은 앱을 전달할 수도 있습니다 이번 세션에서는 현실에서 마주칠 법한 상황을 기반으로 Xcode Cloud에서의 작업흐름을 만들어 보겠습니다 팀의 규모와 형태는 다양하죠 개발 프로세스도 다양하고 특수하고요 실용적인 작업흐름 디자인을 돕기 위해 우리는 세 가지 가설 사례 연구를 상상해 볼 겁니다 각각은 우리가 Xcode Cloud를 채택할 때 흔히 볼 수 있는 상황들과 닮아 있을 겁니다

그래서 단일 앱 작업 중인 솔로 개발자부터 살펴보고 기존 코드와 복잡한 개발 프로세스를 처리하는 대규모 팀의 사례까지 살펴보도록 하겠습니다 이번 세션에서는 어느 팀에나 맞는 작업흐름을 만들고 맞춤화하는 데에 이용할 수 있는 옵션을 볼게요

첫 번째 사례 연구부터 시작해 보겠습니다 솔로 개발자가 있다고 해봅시다 iOS와 macOS에서 둘 다 이용 가능한 앱이 있고요 코딩 작업 대부분은 메인 브랜치에서 이루어집니다 새로운 코드 변경 내용이 모두 반영되죠 떄떄로 새 API나 플랫폼 기능 실험 시 다른 브랜치를 사용하기도 하고요 하지만 대부분 메인 브랜치를 사용합니다 코드는 두 가지 종속성에 의존하고 Cocoapods를 다운로드해 프로젝트에 통합시켰습니다 마지막으로 TestFlight를 통해 앱 사용 및 테스트와 피드백 제공이 가능한 주변인들에게 빌드를 배포했죠 가끔은 App Store에 새로운 버전의 앱을 직접 출시합니다 이 개발자는 1인 쇼죠 앱 구축에서부터 App Store 배포에 이르기까지 모든 것을 솔로 개발자 홀로 관리하고 있습니다 이들에게는 간단함이 아주 중요할 겁니다 의존하고 유지할 수 있는 무언가도 필요할 거고요 Xcode Cloud가 있다면 새 코드 반영 앱 구축, 테스터로의 배포까지 모든 과정이 작지만 거대한 작업흐름에서 이루어질 수 있습니다 이 작업흐름이 어떨지 더 알아보기 전에 잠시 멈춰서 Xcode Cloud 작업흐름을 다시 살펴보죠 앱 구축이나 테스트 실행 테스터에게로의 배포 등이 있을 겁니다 그리고 그 장소는 사용하려는 Xcode와 macOS 버전이고요 환경 변수와 같은 다른 설정들 이외에 말이죠 또한 이들은 작업흐름 실행을 원하는 환경을 형성합니다 마지막으로 그 시기는 원하는 액션의 발생 시점을 말하죠

특정 브랜치에 코드 반영 시 액션이 시작되길 원하나요? 아니면 매일 오후 4시요? 하나 이상의 시작 조건을 정의하는 것은 언제 작업흐름 실행을 원하는지 그 기준을 설정하는 겁니다 좋습니다 다시 한번 되새기고 우리 솔로 개발자의 상황에 대상과 장소, 시기를 적용해 보도록 하죠 저는 이들이 전 프로세스 자동화에 사용할 수 있는 Xcode Cloud 작업흐름을 만들 겁니다 이미 Xcode Cloud에 프로젝트를 설정해 놓았고요 리포트 네비게이터에서 제품명이 적힌 클라우드 아이콘을 우클릭하고 Manage Workflows를 선택하세요

그럼 작업흐름 에디터가 열리죠 +를 누르면 메뉴가 열립니다 첫 번째 항목을 선택해 새 작업흐름을 만들 수 있고요 Name 필드에는 CI Workflow라고 입력할게요 Description 필드는 비워두겠지만 자유롭게 채워보세요 이제 Environment 섹션을 봅시다 이 섹션을 보니 Xcode와 MacOS의 최신 버전이 기본으로 선택되어 있네요 변경할 게 없어서 좋네요 각 작업흐름에는 기본 시작 상태가 따라옵니다 한번 보죠

이 시작 상태는 기본 브랜치에 변경 사항이 반영될 때마다 빌드를 만들게 되는데요 여기서는 main이겠네요 거의 다 됐지만 솔로 개발자는 코드가 메인 브랜치뿐 아니라 어떤 브랜치에 반영돼도 빌드가 시작되길 원한다면요? Sourch Branch 옵션을 Any Branch로 바꾸겠습니다

이 작업흐름의 목표는 앱을 구축하고 배포하는 겁니다 빌드의 배포 준비를 위해 Archive 액션이 필요하고요 Actions 섹션 옆에 +를 클릭해 Archive를 선택하겠습니다

보시다시피 iOS 플랫폼이 이미 선택되어 있으니 Deployment Preparation 섹션에서 TestFlight and App Store 옵션을 선택하겠습니다

이제 작업흐름이 배포 가능한 빌드를 생산할테니 빌드를 App Store Connect에 업로드하는 포스트액션을 추가하죠 이를 위해 Post Actions 섹션의 +를 누르고 TestFlight External Testing을 선택하겠습니다

여기서는 Groups 섹션의 +를 클릭하여 테스터 그룹을 Friends and Family로 설정하죠

이렇게 하면 거의 끝입니다 솔로 개발자는 iOS와 macOS 타겟 앱을 개발 중이니 두 플랫폼에서 앱을 보관하고 출시할 수 있으면 좋겠네요 이를 위해 또 다른 Archive 액션을 추가하겠습니다

macOS 플랫폼과 TestFlight App Store를 선택하죠

그다음 TestFlight External Testing 포스트액션을 추가할 건데요

Archive - macOS 아티팩트를 선택하세요

테스터는 동일 그룹을 선택하시고요

마지막으로 Save를 눌러 작업흐름을 만들어 보죠

이 개발자는 Cocoapads로 앱이 필요로 하는 종속성을 포함시킨다고 말씀드렸었습니다 Xcode Cloud는 특별히 Swift Package Manager를 지원하죠 Xcode에 바로 구축되어 있습니다 하지만 Xcode Cloud에서는 다른 종속성 관리자도 사용될 수 있죠 약간의 환경 설정이면 됩니다 인기 종속성 관리자 일부를 사용하는 법에 관한 문서들도 있습니다 다른 관리자 사용 방법의 가이드로 사용될 수 있고요 여기서는 이 솔로 개발자에게 포스트클론 커스텀 스크립트로 Cocoapods 툴을 설치 및 실행하라고 제안하네요

커스텀 빌드 스크립트는 Xcode Cloud 빌드의 특정 지점에서 추가 액션 실행 방식을 제공합니다 이 경우 포스트클론 스크립트는 모든 소스 코드가 임시 빌드 환경에 복제된 후 실행됩니다 이후 연구 사례에서 또 다른 예시를 살펴볼게요 여기까지가 솔로 개발자의 작업흐름입니다! 다음 코드 반영 시 Xcode Cloud 빌드가 시작되고 앱은 iOS와 macOS에 둘 다 기록될 겁니다 새 빌드는 가족과 친구들의 손에 들어가게 되고 이들이 앱을 테스트하고 피드백을 제공해주겠죠 이제 한 단계 더 나아가 중간 규모 팀 사례를 보죠 전 세계에 걸쳐 개발자, 프로젝트 관리자 QA 엔지니어로 구성된 팀이 있다고 가정해 봅시다 이들은 iPhone, iPad용 iOS 앱을 구축하죠 각 개발자는 각자의 브랜치에서 일합니다 변경 사항을 beta라는 이름의 브랜치로 다시 병합하려고 pull 요청을 사용하고요 내부 QA팀은 해당 브랜치에서 만든 빌드를 설치하고 테스트해 앱과 그 기능이 의도한 대로 작동하도록 보장합니다

앱의 새 버전을 출시하고 싶다면 베타 브랜치를 출시 브랜치에 병합하여 출시를 알리기 위해 새로운 태그를 반영하죠 버그를 잡고 회귀를 피하기 위해 앱은 유닛과 UI 테스트에서 아주 신중히 테스트됩니다 이들은 TestFlight를 사용해 개발 중 다양한 지점에 있는 내, 외부 개발자들에게 앱을 배포합니다 마지막으로 Slack을 통해 작업에 관한 소통을 합니다 상당히 흔한 예시죠 이들은 툴을 사용해 동시에 일하고 협력하며 자신들에 대한 높은 기대치를 갖고 있습니다 이들의 프로세스는 세 가지 Xcode Cloud 작업흐름으로 구현되죠 먼저 저는 pull 요청 작업흐름을 만들 겁니다 이건 변경 내용이 베타 브랜치에 가도록 도와주죠 그다음에는 베타 작업흐름을 만들 거고요 이 경우 내부 빌드가 QA팀에게 입수됩니다 마지막으로 앱의 새 버전을 외부 테스터와 App Store에 출시하는 최종 작업흐름입니다 이 순서대로 살펴보도록 하겠습니다 이 팀에서는 앱에 모든 코드 변경 사항을 통합하기 위해 pull 요청을 사용합니다 개발자가 pull 요청을 열면 팀원이 코드를 검토하고 테스트를 실행해 앱이 예상대로 작동하는지 확인하죠 이 첫 작업흐름에서는 새 pull 요청이 열릴 때 혹은 기존 요청 업데이트 시 테스트가 실행됩니다 이 작업흐름을 만들어 보죠 먼저 + 표시를 클릭해 새 작업흐름을 만들어 볼게요 Name 필드에는 Pull Requests라고 입력하겠습니다 이 경우 팀에서는 pull 요청이 열렸을 때와 '베타' 브랜치가 타겟일 때 빌드를 시작하기를 원합니다 각 빌드에 대해 테스트 실행도 원하고요 새로운 시작 상태를 추가하는 것으로 시작해 보죠 Start Conditions 섹션의 + 표시를 클릭하고 Pull Request Changes 항목을 선택하겠습니다 기본적으로 어느 브랜치에서든 빌드가 시작되기에 Target Branch 섹션에서 Custom Branches를 선택하죠 그다음 + 버튼을 클릭해 beta라고 입력할게요

우리는 하나의 시작 상태만 요구했습니다 이제 Branch Changes 섹션은 삭제할게요

이제 테스트 실행을 위해 새 액션을 추가하겠습니다 Actions 섹션 +를 눌러 Test를 선택하죠

이 앱은 iOS와 iPadOS를 타겟으로 합니다 그래서 이 팀은 테스트가 다양한 화면 크기와 기능에서 통과하기를 원하죠 Destination 섹션에서 작은 iPhone 중 하나인 iPhone 13을 선택하고 더 큰 iPhone인 iPhone 14 Pro Max를 선택하고

작은 iPad인 iPad mini를

큰 iPad인 iPad Pro를 선택하겠습니다

그다음 Save 버튼을 누를게요

아주 좋습니다 Xcode Cloud에서 빌드를 성공적으로 끝냈으니 팀원들이 전체 코드를 검토했으면 하는데요 개발자는 pull 요청을 병합해 변경사항을 베타 브랜치로 가져갈 수 있을 겁니다 이건 가뿐하게 다음 작업흐름으로 데려다주죠 베타 빌드 작업흐름입니다

베타 브랜치에는 향후 변경 사항이 입력됩니다 개발자가 pull 요청을 병합하면 QA팀은 앱의 빌드에 변경 사항을 포함하고 싶겠죠 검증 테스트를 수행할 수 있도록 말입니다 이건 이 새로운 작업흐름의 기본 사항입니다 빌드를 QA팀에 배포하는 것 말이죠 Xcode로 가서 작업흐름을 만들어 보죠

이 베타 작업흐름은 이전 작업흐름의 조합입니다 이 팀은 변경 사항이 베타 브랜치에 병합될 때마다 빌드를 출시하고자 합니다 테스트를 실행하고 앱을 기록하고 App Store Connect에 업로드하는 작업흐름이 필요하죠 이 작업을 시작해 보죠

Beta Release라고 이름을 설정하겠습니다

그에 따라 시작 상태를 업데이트하세요 기존의 Branch Changes 시작 상태를 선택하고 브랜치를 Main에서 Beta로 바꿀 겁니다

그다음 Archive 빌드 액션을 추가할 건데요

Deployment Preparation에서 TestFlight Internal Testing을 선택하세요

그럼 내부 배포를 사용하는 겁니다 이 빌드가 실수로 생산되기를 원하지는 않으니까요 이제 App Store Connect로 업로드하는 포스트 빌드를 추가합니다 이 포스트액션은 앱을 내부 테스터들에게 배포할 겁니다 TestFlight Internal Testing 포스트액션을 추가할게요

Groups 섹션에서 + 표시를 클릭해 QA Team을 선택하세요

좋습니다 여기서 끝내도 되는데요 브로큰 빌드를 배포할 위험은 피하고 싶습니다 안전망으로서 작업흐름의 일환으로 테스트를 실행할게요 pull 요청 작업흐름에서 테스팅 액션을 반복할 겁니다 다시 한번 작은 iPhone 더 큰 iPhone 작은 iPad

더 큰 iPad를 선택하죠

Save 버튼을 눌러 작업흐름 만들기를 끝냅시다

베타 빌드 작업흐름은 빌드를 QA팀에 전달하지만 여기서 팀이 원하는 게 한 가지 더 있습니다 베타 빌드용 앱 아이콘을 다른 걸 사용하고 싶은 거죠 그래서 어떤 빌드가 내부용인지 App Store용인지를 빠르게 결정할 수 있습니다 Xcode Cloud의 클라우드 스크립트가 여기서 도움이 되죠

소스 코드 복제 후 실행되는 커스텀 스크립트 기억하시죠? 여기서는 아이콘 변경을 위해 프리빌드 스크립트를 사용할게요

스크립트에서 이용 가능한 환경 변수를 사용하여 베타 작업흐름의 빌드 단계에서 아이콘 변경만 할 수 있도록 해보겠습니다 이를 달성하는 법에 대해 더 알아보고 싶다면 WWDC21 세션 중 아래 세션을 확인해 주세요 이 정확한 사용 사례를 구체적으로 담고 있습니다 우리는 커스텀 스크립트 3개 중 2개만 사용했는데요 다른 스크립트로 또 뭐가 있는지 그리고 어떤 환경 변수를 이용할 수 있는지 궁금하다면 우리 개발자 문서에서 상세한 설명을 얻어 보세요 베타 빌드 작업흐름은 여기까지입니다 이제 최종 작업흐름인 '출시 작업흐름'을 살펴보죠 베타 브랜치에 여러 변경 사항이 랜딩되고 QA팀이 검증한 이후 새 출시를 준비할 겁니다

이 프로세스에선 개발자 한 명이 베타 브랜치를 출시 브랜치에 병합하고 출시 표시 태그를 만들어야죠 태그 이름은 'relase' 그리고 버전 순입니다 이게 완료되면 앱이 구축되고 App Store Connect에 업로드되죠 그 다음 내부 이해관계자와 일부 열정적인 고객에게 배포될 겁니다 이 마지막 작업흐름은 베타 작업흐름과 유사하죠 새 출시 태그가 반영될 때 빌드가 만들어지는 걸 제외하고요 Xcode로 돌아가서 이 작업흐름도 만들어 봅시다 여기서 필요한 단계들은 베타 작업흐름에서 했던 것과 거의 정확하게 일치하는데요 시작 상태를 만들고 앱을 기록하는 등 동일한 단계를 쭉 거칠 수 있습니다 대신 여기서 베타 작업흐름을 복제할 수 있는 Xcode Cloud 기능을 안내해 드릴게요 먼저 Beta Workflow를 우클릭하고 Duplicate를 클릭하신 후 이름을 Beta에서 Release로 변경해 주세요

이제 새 시작 상태를 추가할 겁니다 Start Conditions 섹션의 +를 클릭하고 Tag Changes를 선택하세요

브랜치 변경과 유사하게 태그 반영 때마다 빌드 만들기를 원치는 않습니다 태그 이름이 relase라는 단어로 시작할 때만 원하죠 Tag 섹션에서 Custom Tags를 선택하겠습니다 release를 입력하시고

메뉴에서 tags beginning with release/를 선택하세요 이 시작 상태가 만들어지면 기존의 Branch Changes 시작 상태로 돌아가서 삭제할 겁니다 이제 기존 Archive 액션으로 움직여 보죠 베타 작업흐름은 내부 배포를 위해 만들었는데요 특히 QA팀에 말이죠 여기서는 외부 테스팅과 App Store 출시를 원합니다 Deployment Preparation 섹션에서 Testflight and App Store 옵션을 선택할게요 빌드를 이해관계자 내부팀에는 여전히 배포를 원한다는 거죠 이제 기존 포스트 빌드 액션을 선택하고 QA Team을 삭제할게요

그리고 이 +를 클릭해 Executive Stakeholders 그룹을 선택하겠습니다 마지막으로 또 다른 포스트 액션을 추가할 건데요 이번에는 TestFlight External Testing을 선택하겠습니다 Post Actions 섹션의 + 표시를 클릭하고 TestFlight External Testing을 선택할게요 그 다음 Groups 섹션의 +를 클릭하고 Early Adopters를 선택할 거고요

이제 출시 작업흐름 준비가 거의 끝났습니다 이 팀에서는 서로 소통하고 협력하기 위해 Slack을 사용한다고 말씀드렸었죠? Slack에서 빌드에 대한 업데이스 소식을 얻는 건 그들의 개발 과정과 완전히 일치할 겁니다 빌드 에러 시, 혹은 출시 불가 시 특히 중요하죠 최종 단계를 작업흐름에 추가해 봅시다 출시 작업흐름에서 Post Actions 섹션의 +를 클릭하고 Notify를 선택하겠습니다 Xcode Cloud는 이메일과 Slack을 통한 알림을 지원하죠 여기서 Slack 아래에 있는 + 표시를 클릭해 Releases Feed 채널을 선택한 후 OK를 누를게요 이게 두 번째 사용 사례의 끝입니다 세 작업흐름이 팀 개발 프로세스를 포괄하죠 이 작업흐름들은 앱을 빌드해 지속적으로 테스트를 실행해서 개발자들이 확신을 가지고 배포할 수 있게 해줍니다 앱을 자주 기록하고 배포해 다양한 사람들이 피드백 제공을 할 수 있죠 상당히 흔한 상황입니다 어느 프로세스에나 적응되는 툴의 도움으로 최고 품질의 앱을 출시할 수 있다는 게 말이죠 이제 마지막 사용 사례로 이걸 더 보여드리죠 더 큰 팀이 Xcode Cloud를 전환하려고 합니다 최종 사례는 대규모 개발팀과 관련됩니다 이 팀은 중간 규모 팀과 많은 유사점을 갖고 있죠 몇 가지만 조금 다르고요 이 팀은 더 크고 훨씬 복잡한 코드 베이스입니다 iOS와 iPadOS에서 작동하는 앱을 가지고 있죠 거의 App Store의 시작부터 함께 하고 있습니다 이후 몇 번이나 재디자인과 업데이트를 거쳤고 개발자들은 기존 코드와 복잡성 다수를 처리하고 있죠 특히 QA를 할 때요 많은 테스트를 실행합니다 최근에는 테스트 기반 개발법을 채택했고 많은 테스트들이 코드 변경마다 추가되고 있죠

많은 사람들이 이 앱의 성공적인 업데이트에 관여했고 그래서 새 빌드를 여러 Test Flight 그룹에 배포합니다 내, 외부 상관 없이 피드백을 얻기 위해서요 이 팀에는 전 세계 많은 개발자들이 포함되며 이들은 Slack을 통해 소통 및 협력하고 있습니다 여기서 흥미로운 차이가 나타나는데요 이들은 이미 지속적인 통합과 계속된 배포를 통해 작업을 완료했습니다 현재 팀 구성원 한 명이 유지보수 및 운영하는 인하우스 솔루션을 사용하고 있죠 시스템 접근과 시스템에 대한 정보는 제한되어 문제를 조사하고 해결하기도 힘들게 만들죠 이러한 이유로 이들은 인하우스 솔루션 대체를 위해 Xcode Cloud로의 전환을 고려 중입니다 또한 프로젝트 관리 툴로 진행 중인 작업을 추적 조정, 우선순위화하고 있는데요 다양한 대시보드와 상태 페이지도 만들었습니다 이렇게 앱 개발과 직접 관련이 없는 사람도 프로젝트 진행 상황을 추적할 수가 있습니다 Xcode Cloud는 이런 팀에게는 안성맞춤이나 이 복잡한 프로젝트를 새 CI 시스템으로 이전하려면 힘들기도 하고 버겁게 느껴질 수 있습니다 이 상황에서는 이전을 여러 가지 이정표로 나눠보기를 권장합니다 각 이정표엔 일정 기간에 걸쳐 워크로드를 기존 시스템에서 Xcode Cloud로 이동시키는 것이 포함되죠 여기서 중요한 점은 성공적인 이전을 하면서도 팀이 생산적이고 기뻐야 한다는 겁니다 작업흐름 구성 대신 그 이정표들이 어떤 것들인지 한번 살펴보도록 하죠 전 이전을 특정 이정표들로 분할하길 추천하는데요 첫 번째는 App Store에 출시될 수 있는 버전의 앱을 빌드하는 작업흐름을 만드는 겁니다 두 번째는 테스트를 신뢰할 수 있게 진행하는 것 세 번째는 팀 개발 프로세스에 맞추고 개선하기도 하는 작업흐름을 확립하는 것이죠 이 단계들을 각각 자세하게 살펴볼 겁니다 우선 출시 작업흐름부터 살펴보겠습니다

Xcode Cloud로 이전할 때 우선 App Store용 빌드를 기록하고 업로드하는 작업흐름을 만드는 것으로 시작하는 건데요 이건 우리가 이미 만든 예시 작업흐름이 될 수 있고 나머지 팀원들에 대해 중단 없이 달성 가능합니다 여기서부터 시작해 Xcode Cloud에 바로 구축되는 클라우드 코드 서명 기능 사용이 가능합니다 빌드 서명을 위한 인증이나 프로파일 권한 설정이 필요없죠 종속성과 이외 구성 변경 사항에 관하여 앱을 성공적으로 구축하려면 뭐가 필요한지 확인할 수 있는 좋은 방법이기도 합니다 이 작업흐름이 준비되면 팀의 정규 개발 프로세스에 App Store용 빌드를 만드는 부분으로 포함될 수 있습니다 이건 기존 시스템에서 벗어나 Xcode Cloud로 옮기기 위한 최초의 작업이고요 이제 신뢰 가능한 테스트가 작동 중인지 봐야 합니다 테스팅은 지속 통합 시스템에서 매우 까다로울 수 있습니다 종종 테스트는 만들어진 때 사용되고 있던 CI 환경에서 작동하도록 설정되어 있었을 겁니다 새 CI 환경에서 실행하면 신뢰 가능하게 작동하지 못해 빌드가 에러를 일으키게 하죠 Xcode Cloud를 만들던 당시 우리는 이 특정 문제를 고려해 팀이 테스트를 매끄럽게 실행할 수 있도록 도와줄 수있다고 믿는 기능을 구축해 놓았습니다 이 기능은 Xcode Cloud가 작업흐름 내 액션 일부에서 오류를 무시하고 빌드를 끝내게 합니다

이 기능을 활성화하기 위해 작업흐름의 Action 섹션의 Requirement 아래 Not Required To Pass 옵션을 선택하죠 액션을 이렇게 지정함으로써 이 액션의 결과는 Xcode Cloud 빌드 최종 결과에 영향을 주지 않습니다 테스트 에러가 날 순 있지만 빌드는 그럼에도 완료되죠 Xcode Cloud에서 여전히 초록색 표시가 보일 겁니다 빌드의 Source Code Management 커미트 상태에서도요

이건 주요 경로를 벗어나는 테스트를 지속적으로 시행할 수 있다는 뜻이기에 굉장히 유용합니다 이렇게 데이터를 통합해서 어떻게 수행 중인지 얼마나 신뢰 가능한지를 평가할 수 있죠 이제 이 기능을 사용한 테스트 실행법을 살펴봅시다

이 팀에는 앱의 여러 측면을 다루는 테스트들이 있는데요 이런 상황에서는 모든 pull 요청을 위해 실행할 새로운 작업흐름 만들기로 시작하시길 권장합니다 여기에서는 하나의 빌드 액션이 모든 테스트를 실행하지만 Not Required To Pass라고 표시됩니다 테스트 결과에 상관없이 pull 요청 통합을 막지 못한다는 거죠 이제 이 아이디어가 테스트 신뢰도를 평가합니다 테스트는 기존 솔루션에서도 실행 중임을 기억하세요 pull 요청은 시간이 지나도 확실히 병합됩니다 팀에서는 pull 요청 빌드에서 테스트 결과 확인이 가능한데요 Xcode Cloud에서 신뢰할 수 있게 통과한 테스트 확인도 가능하죠 이들은 Reliable Tests라는 새 Test Plan으로 이동합니다 그럼 팀에서는 기존의 pull 요청 작업흐름을 편집해 특정 테스트 플랜의 테스트를 실행하는 새 액션을 추가하죠 이번에는 테스트 액션이 pull 요청이 병합되기 전에 통과하도록 요청될 겁니다 Xcode Cloud에서의 테스트 플랜 사용법에 대해서는 첫 번째 줄에 있는 WWDC22 섹션에서 알아보시길 바랍니다 테스트 플랜을 사용해 코드 평가를 개선하는 법은 개발자 문서에서 참고해 주시고요 남은 테스트는 현재 신뢰할 수 있게 수행 중이지 않은 것들로 추가적으로 조사하여 어떤 변화가 필요한지 알아볼 수 있습니다 시간이 지나고 변동이 생기면 다시 신뢰될 수도 있죠 결국 신뢰 가능한 테스트 플랜으로 이동하여 다시 변경 사항에 대한 검증에 사용될 수 있습니다 이 접근법을 통해 테스트를 주요 경로로 단계별로 이동하고 Xcode Cloud 작업흐름에서 검증과 테스트 커버리지를 제공할 수 있습니다

일단 테스트가 실행 중이라 좋으실 텐데요 이제 App Store용 빌드와 테스트가 있어 Xcode Cloud에서 신뢰 가능하게 실행됩니다 그럼 기존 CI 솔루션에서 두 워크로드가 제거되죠 이제 마지막 단계만 남았는데요 팀 개발 프로세스에 필요한 작업흐름을 마저 구축하는 거죠 이런 작업흐름 중 일부는 이번 세션 이전 사례들에서 봤던 것들과 유사할 겁니다 시작 상태와 액션에 대한 다양한 사용자화를 통해 CI, CD 프로세스 자동화를 도울 수 있는 강력한 작업흐름 도구를 만들 수 있습니다 이 팀이 CI 시스템 외부에 툴과 대시보드를 만들었다고 말씀드렸었는데요 그 툴들은 개발 프로세스 파악에 도움이 됩니다 Xcode Cloud에도 통합될 수 있고요 가령 웹훅 기능을 사용한다고 해보죠 웹훅시 설정되면 빌드가 완료될 때마다 빌드와 그 빌드를 시작한 작업흐름 등의 정보와 함께 하나의 요청이 서버로 송신됩니다 베타 작업흐름에서 빌드가 만들어져 성공했다면 태스트 관리 시스템에 새 티켓을 만들어 이 특정 필드에 대한 QA 프로세스 추적이 가능하죠

웹훅에 대해서도 물론이고 그런 요청이 언제 송신되는지 어떤 정보를 이용할 수 있는지 더 알아보고 싶다면 개발자 문서를 확인하세요 또 다른 접근법은 Xcode Cloud 개방형 API를 사용하는 겁니다 다른 것들 사이에서 최근 빌드 관련 정보를 가져와 대시보드나 상태 페이지에 보여줄 수 있습니다

Xcode Cloud의 개방형 API 사용법과 작업흐름에 통합하는 법을 알아보고 싶으시다면 이것 또한 개발자 문서를 확인해 주세요 Xcode Cloud의 개방형 API와 웹훅 메커니즘은 팀 규모와 상관 없이 특히 유용한 기능입니다 모든 옵션을 조합하면 가능성은 무한대가 되죠 WWDC22에서 진행된 다음 세션을 참고해 주시고요 이번 세션에서는 팀 생산력 향상을 위한 단순하지만 강력한 작업흐름들을 살펴 봤습니다 빌드의 다양한 지점에서 빌드 스크립트를 사용해 빌드 프로세스를 사용자화하는 방법의 예시를 보여드렸는데요 마지막으로는 이런 기능 일부가 Xcode Cloud에서 툴을 구축해 외부 툴에 통합하는 방법도 살펴봤습니다 세 가지 사례 연구를 통해 Xcode Cloud를 여러분 팀에 맞춰 일상 업무 개선을 이끌어낼 수 있길 바랍니다 시청해 주셔서 감사합니다 ♪ ♪