Xamarin에서 TeamCity 사용
이 가이드에서는 TeamCity를 사용하여 모바일 애플리케이션을 컴파일한 다음 App Center 테스트에 제출하는 데 관련된 단계를 설명합니다.
CI(연속 통합 소개 가이드)에서 설명한 것처럼, CI(연속 통합)는 고품질 모바일 애플리케이션을 개발할 때 유용한 방법입니다. 연속 통합 서버 소프트웨어에 대한 많은 실행 가능한 옵션이 있습니다. 이 가이드에서는 JetBrains의 TeamCity에 초점을 맞춥다.
TeamCity 설치에는 여러 가지 순열이 있습니다. 다음 목록에서는 이러한 순열 중 일부를 설명합니다.
Windows 서비스 – 이 시나리오에서는 Windows가 Windows 서비스로 부팅되면 TeamCity가 시작됩니다. iOS 애플리케이션을 컴파일하려면 Mac 빌드 호스트와 페어링해야 합니다.
OS X 에서 디먼 시작 – 개념적으로 이전 단계에서 설명한 Windows 서비스로 실행되는 것과 비슷합니다. 기본적으로 빌드는 루트 계정에서 실행됩니다.
OS X 의 사용자 계정 – 사용자가 로그인할 때마다 시작되는 사용자 계정으로 TeamCity를 실행할 수 있습니다.
이전 시나리오 중 OS X의 사용자 계정으로 TeamCity를 실행하는 것이 가장 간단하고 쉽게 설정할 수 있습니다.
TeamCity 설정과 관련된 몇 가지 단계가 있습니다.
TeamCity 설치 – TeamCity 설치는 이 가이드에서 다루지 않습니다. 이 가이드에서는 TeamCity가 사용자 계정으로 설치되고 실행되고 있다고 가정합니다. TeamCity 설치에 대한 지침은 JetBrains의 TeamCity 8 설명서에서 찾을 수 있습니다.
빌드 서버 준비 – 이 단계에는 모바일 애플리케이션을 빌드하고 배포를 준비하는 데 필요한 소프트웨어, 도구 및 인증서를 설치하는 작업이 포함됩니다.
빌드 스크립트 만들기 – 이 단계는 반드시 필요한 것은 아니지만 빌드 스크립트는 무인 애플리케이션을 빌드하는 데 유용한 도움이 됩니다. 빌드 스크립트를 사용하면 발생할 수 있는 빌드 문제를 해결하는 데 도움이 되며, 연속 통합이 실행되지 않더라도 배포를 위한 이진 파일을 만드는 일관되고 반복 가능한 방법을 제공합니다.
TeamCity 프로젝트 만들기 – 이전 세 단계가 완료되면 소스 코드를 검색하고, 프로젝트를 컴파일하고, App Center 테스트에 테스트를 제출하는 데 필요한 모든 메타 데이터를 포함하는 TeamCity 프로젝트를 만들어야 합니다.
App Center 테스트 경험이 필요합니다.
TeamCity 8.1에 대한 숙지가 필요합니다. TeamCity 설치는 이 문서의 범위를 벗어습니다. TeamCity는 OS X Mavericks에 설치되고 루트 계정이 아닌 일반 사용자 계정으로 실행되고 있다고 가정합니다.
빌드 서버는 연속 통합 전용인 OS X를 실행하는 독립 실행형 컴퓨터여야 합니다. 이상적으로 빌드 서버는 데이터베이스 서버, 웹 서버 또는 개발자 워크스테이션과 같은 다른 역할을 담당하지 않습니다.
중요
이 가이드에서는 Xamarin의 "헤드리스" 설치를 다루지 않습니다.
테스트를 Xamarin Test Cloud에 제출하려면 테스트를 제출하는 컴퓨터가 테스트 클라우드 서버와 통신할 수 있어야 합니다. 포트 80 및 443의 testcloud.xamarin.com 있는 서버에서 네트워크 트래픽을 허용하도록 방화벽을 구성해야 합니다. 이 엔드포인트는 DNS에서 관리되며 IP 주소는 변경될 수 있습니다.
경우에 따라 테스트(또는 테스트를 실행하는 디바이스)가 방화벽으로 보호되는 웹 서버와 통신해야 합니다. 이 시나리오에서는 다음 IP 주소의 트래픽을 허용하도록 방화벽을 구성해야 합니다.
- 195.249.159.238
- 195.249.159.239
빌드 서버를 구성하는 중요한 단계는 모바일 애플리케이션을 빌드하는 데 필요한 모든 도구, 소프트웨어 및 인증서를 설치하는 것입니다. 빌드 서버가 모바일 솔루션을 컴파일하고 테스트를 실행할 수 있어야 합니다. 구성 문제를 최소화하려면 TeamCity를 호스팅하는 동일한 사용자 계정에 소프트웨어 및 도구를 설치해야 합니다. 다음 목록에서는 필요한 사항을 자세히 설명합니다.
- Mac용 Visual Studio – Xamarin.iOS 및 Xamarin.Android가 포함됩니다.
- Xamarin 구성 요소 저장소 에 로그인 – 이 단계는 선택 사항이며 애플리케이션이 Xamarin 구성 요소 저장소의 구성 요소를 사용하는 경우에만 필요합니다. 이 시점에서 구성 요소 저장소에 사전에 로그인하면 TeamCity 빌드에서 애플리케이션을 컴파일하려고 할 때 문제가 발생하지 않습니다.
- Xcode – iOS 애플리케이션을 컴파일하고 서명하려면 Xcode가 필요합니다.
- Xcode 명령줄 도구 – rbenv를 사용하여 Ruby 업데이트 가이드의 설치 섹션 1단계에서 설명합니다.
- 서명 ID 및 프로비전 프로필 – XCode를 통해 인증서 및 프로비저닝 프로필을 가져옵니다. 자세한 내용은 서명 ID 내보내기 및 프로비전 프로필에 대한 Apple 가이드를 참조하세요.
- Android 키 저장소 – TeamCity 사용자가 액세스할 수 있는 디렉터리에 필요한 Android 키 저장소를 복사합니다. 즉
~/Documents/keystores/MyAndroidApp1
, - Calabash – 애플리케이션에 Calabash를 사용하여 작성된 테스트가 있는 경우 선택적 단계입니다. 자세한 내용은 OS X 매버릭스에 칼라바시 설치 가이드 및 rbenv 가이드를 사용하여 Ruby 업데이트 가이드를 참조하세요.
다음 다이어그램에서는 이러한 모든 구성 요소를 보여 줍니다.
모든 소프트웨어가 설치되면 사용자 계정에 로그인하고 모든 소프트웨어가 제대로 설치되고 작동하는지 확인합니다. 여기에는 솔루션을 컴파일하고 App Center 테스트에 애플리케이션을 제출하는 작업이 포함되어야 합니다. 다음 섹션에 설명된 대로 빌드 스크립트를 실행하여 이를 간소화할 수 있습니다.
TeamCity는 모바일 애플리케이션을 컴파일하고 App Center 테스트에 제출하는 모든 측면을 단독으로 처리할 수 있지만 빌드 스크립트를 만드는 것이 좋습니다. 빌드 스크립트는 다음과 같은 이점을 제공합니다.
- 설명서 – 빌드 스크립트는 소프트웨어 빌드 방법에 대한 설명서의 한 형태로 사용됩니다. 이렇게 하면 애플리케이션 배포와 관련된 일부 "매직"이 제거되고 개발자가 기능에 집중할 수 있습니다.
- 반복성 – 빌드 스크립트는 애플리케이션이 컴파일되고 배포될 때마다 누가, 무엇을 하든 동일한 방식으로 수행되도록 합니다. 이 반복 가능한 일관성은 잘못 실행된 빌드 또는 사용자 오류로 인해 나타날 수 있는 모든 문제 또는 오류를 제거합니다.
- 버전 관리 – 빌드 스크립트를 소스 제어 시스템에 포함할 수 있습니다. 즉, 오류 또는 부정확성이 발견되면 빌드 스크립트의 변경 내용을 추적, 모니터링 및 수정할 수 있습니다.
- 환경 준비 - 빌드 스크립트에는 필요한 타사 종속성을 설치하는 논리가 포함될 수 있습니다. 이렇게 하면 애플리케이션이 적절한 구성 요소로 빌드됩니다.
빌드 스크립트는 PowerShell 파일(Windows) 또는 bash 스크립트(OS X)만큼 간단할 수 있습니다. 빌드 스크립트를 만들 때 스크립팅 언어에 대한 몇 가지 선택 사항이 있습니다.
Rake – Ruby를 기반으로 프로젝트를 빌드하기 위한 Do기본 특정 언어(DSL)입니다. Rake는 인기와 풍부한 라이브러리 에코시스템의 장점을 가지고 있습니다.
psake – 소프트웨어 빌드를 위한 Windows PowerShell 라이브러리입니다.
FAKE – F#을 기반으로 하는 DSL로, 필요한 경우 기존 .NET 라이브러리를 사용할 수 있습니다.
사용되는 스크립팅 언어는 기본 설정 및 요구 사항에 따라 달라집니다.
참고
MSBuild 또는 NAnt와 같은 XML 기반 빌드 시스템을 사용할 수 있지만 소프트웨어 빌드 전용 DSL의 표현성 및 기본 지속성이 부족합니다.
소프트웨어를 빌드하고 테스트하는 프로세스에는 비밀로 유지해야 하는 정보가 필요합니다. APK를 만들려면 키 저장소 및/또는 키 저장소의 키 별칭에 대한 암호가 필요할 수 있습니다. 마찬가지로 App Center 테스트에는 개발자에게 고유한 API 키가 필요합니다. 이러한 유형의 값은 빌드 스크립트에서 하드 코딩하면 안 됩니다. 대신 빌드 스크립트에 변수로 전달되어야 합니다.
iOS 디바이스 ID 또는 App Center가 테스트 실행에 사용해야 하는 디바이스를 식별하는 Android 디바이스 ID와 같은 값은 덜 민감합니다. 보호해야 하는 값은 아니지만 빌드에서 빌드로 변경될 수 있습니다.
이러한 유형의 변수를 빌드 스크립트 외부에 저장하면 조직 내에서 빌드 스크립트를 개발자와 더 쉽게 공유할 수 있습니다. 개발자는 빌드 서버와 정확히 동일한 스크립트를 사용할 수 있지만 자체 키 저장소 및 API 키를 사용할 수 있습니다.
이러한 중요한 값을 저장할 수 있는 두 가지 옵션이 있습니다.
구성 파일 – API 키를 보호하려면 이 값을 버전 제어에 검사 안 됩니다. 각 컴퓨터에 대해 파일을 만들 수 있습니다. 이 파일에서 값을 읽는 방법은 사용되는 스크립팅 언어에 따라 달라집니다.
환경 변수 – 컴퓨터별로 쉽게 설정할 수 있으며 기본 스크립팅 언어와 독립적입니다.
이러한 각 선택에는 장점과 단점이 있습니다. TeamCity는 환경 변수와 잘 작동하므로 이 가이드에서는 빌드 스크립트를 만들 때 이 기술을 권장합니다.
빌드 스크립트는 다음 단계를 수행해야 합니다.
애플리케이션 컴파일 – 올바른 프로비저닝 프로필을 사용하여 애플리케이션 서명이 포함됩니다.
애플리케이션을 Xamarin 테스트 클라우드 에 제출 – APK를 적절한 키 저장소에 서명하고 압축을 맞추는 것이 포함됩니다.
이 두 단계는 아래에서 자세히 설명합니다.
다음 명령줄에서는 i전화 대한 솔루션 SOLUTION_FILE.sln 릴리스 빌드를 지정합니다. 명령줄에서 속성을 지정하여 IPA의 IpaPackageDir
위치를 설정할 수 있습니다.
Mac에서 xbuild 사용:
xbuild /p:Configuration="Release" \ /p:Platform="iPhone" \ /p:IpaPackageDir="$HOME/Builds" \ /t:Build MyProject.sln
xbuild 명령은 일반적으로 /Library/Frameworks/Mono.framework/Commands 디렉터리에 있습니다.
Windows에서 msbuild 사용:
msbuild /p:Configuration="Release" /p:Platform="iPhone" /p:IpaPackageDir="%USERPROFILE%\Builds" /p:ServerAddress="192.168.1.3" /p:ServerUser="macuser" /t:Build MyProject.sln
msbuild 는 명령줄에서 전달된 식을 자동으로 확장 $( )
하지 않습니다. 이러한 이유로 명령줄에서 설정할 IpaPackageDir
때 전체 경로를 사용하는 것이 좋습니다.
속성에 대한 자세한 내용은 iOS 9.8 릴리스 IpaPackageDir
정보를 참조하세요.
Android 애플리케이션을 컴파일하려면 xbuild(또는 Windows의 msbuild)를 사용합니다.
/Library/Frameworks/Mono.framework/Commands/xbuild /t:SignAndroidPackage /p:Configuration=Release /path/to/android.csproj
Android 애플리케이션 xbuild 컴파일은 프로젝트를 사용하는 반면 iOS 애플리케이션 xbuild 는 솔루션을 사용합니다.
UITest는 다음 코드 조각과 같이 App Center CLI를 사용하여 제출됩니다.
appcenter test run uitest --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --merge-nunit-xml report.xml --build-dir pathToUITestBuildDir
테스트를 실행하면 테스트 결과가 report.xml이라는 NUnit 스타일 XML 파일 형식으로 반환됩니다. TeamCity는 빌드 로그에 정보를 표시합니다.
App Center에 UITest를 제출하는 방법에 대한 자세한 내용은 Xamarin.Android 앱 준비 또는 Xamarin.iOS 앱 준비를 참조하세요.
Calabash 테스트는 다음 코드 조각과 같이 App Center CLI를 사용하여 제출됩니다.
appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --project-dir pathToProjectDir
Android 애플리케이션을 App Center Test에 제출하려면 먼저 calabash-android를 사용하여 APK 테스트 서버를 다시 빌드해야 합니다.
$ calabash-android build </path/to/signed/APK>
$ appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK> --project-dir pathToProjectDir
Calabash 테스트 제출에 대한 자세한 내용은 Xamarin의 테스트 클라우드에 Calabash 테스트 제출 가이드를 참조하세요.
TeamCity가 설치되고 Mac용 Visual Studio 프로젝트를 빌드할 수 있으면 TeamCity에서 프로젝트를 만들어 프로젝트를 빌드하고 App Center에 제출해야 합니다.
웹 브라우저를 통해 TeamCity에 로그인하여 시작합니다. 루트 프로젝트로 이동합니다.
루트 프로젝트 아래에 새 하위 프로젝트를 만듭니다.
하위 프로젝트가 만들어지면 새 빌드 구성을 추가합니다.
빌드 구성에 VCS 프로젝트를 연결합니다. 이 작업은 버전 제어 설정 화면을 통해 수행됩니다.
만든 VCS 프로젝트가 없는 경우 아래 표시된 새 VCS 루트 페이지에서 만들 수 있습니다.
VCS 루트가 연결되면 TeamCity는 프로젝트를 검사 빌드 단계를 자동으로 검색합니다. TeamCity에 익숙한 경우 검색된 빌드 단계 중 하나를 선택할 수 있습니다. 지금은 검색된 빌드 단계를 무시해도 안전합니다.
다음으로 빌드 트리거를 구성합니다. 이렇게 하면 사용자가 리포지토리에 코드를 커밋하는 경우와 같이 특정 조건이 충족될 때 빌드가 큐에 대기합니다. 다음 스크린샷은 빌드 트리거를 추가하는 방법을 보여줍니다.
빌드 트리거를 구성하는 예제는 다음 스크린샷에서 확인할 수 있습니다.
이전 섹션에서는 빌드 스크립트를 매개 변수화하여 일부 값을 환경 변수로 저장하는 것이 좋습니다. 이러한 변수는 매개 변수 화면을 통해 빌드 구성에 추가할 수 있습니다. 아래 스크린샷과 같이 App Center API 키, iOS 디바이스 ID 및 Android 디바이스 ID에 대한 변수를 추가합니다.
마지막 단계는 빌드 스크립트를 호출하여 애플리케이션을 컴파일하고 애플리케이션을 App Center 테스트에 큐에 넣는 빌드 단계를 추가하는 것입니다. 다음 스크린샷은 Rakefile을 사용하여 애플리케이션을 빌드하는 빌드 단계의 예입니다.
이 시점에서 빌드 구성이 완료되었습니다. 빌드를 트리거하여 프로젝트가 제대로 구성되었는지 확인하는 것이 좋습니다. 이 작업을 수행하는 좋은 방법은 리포지토리에 작고 중요하지 않은 변경을 커밋하는 것입니다. TeamCity는 커밋을 검색하고 빌드를 시작해야 합니다.
빌드가 완료되면 빌드 로그를 검사하고 주의가 필요한 빌드에 문제가 있는지 또는 경고가 있는지 확인합니다.
이 가이드에서는 TeamCity를 사용하여 Xamarin Mobile 애플리케이션을 빌드한 다음 App Center 테스트에 제출하는 방법을 설명했습니다. 빌드 프로세스를 자동화하는 빌드 스크립트 만들기에 대해 설명했습니다. 빌드 스크립트는 애플리케이션 컴파일, App Center 테스트 제출 및 결과 대기를 처리합니다.
그런 다음 개발자가 코드를 커밋하고 빌드 스크립트를 호출할 때마다 빌드를 큐에 대기하는 TeamCity에서 프로젝트를 만드는 방법을 설명했습니다.