TeamCity가 저장소에 성공적으로 연결되면 다음 대화 상자가 표시됩니다.
Create Project From URL(URL에서 프로젝트 만들기) 대화상자에 프로젝트 이름과 초기 빌드 구성 이름을 변경할 수 있는 옵션이 있습니다.
참고: 최신 버전의 TeamCity에서는 TeamCity가 빌드해야 하는 브랜치를 지정할 수 있는 Default branch(기본 브랜치) 및 Branch specification(브랜치 사양) 필드도 볼 수 있습니다. 지금은 무시하세요.
Proceed(진행)를 클릭하면 TeamCity가 버전 관리 저장소에서 지원되는 기술(이 경우 Python)을 자동으로 검색합니다.
TeamCity가 저장소에서 .py 파일을 찾으면 자동으로 프로젝트에 대해 하나 이상의 빌드 단계를 제안합니다. 이 튜토리얼에서 사용된 저장소의 경우, 이렇게 자동 탐지된 빌드 단계는 main.py 또는 setup.py 파일을 실행하겠지만, 이것은 바라는 바가 아닐 수도 있습니다.
이보다는 Python 프로젝트에 다음 빌드 단계를 기본적으로 추가하는 것이 좋을 것입니다.
자동 탐지된 빌드 단계 중 하나를 선택하는 대신, 이 두 빌드 단계를 프로젝트에 추가해 보겠습니다.
TeamCity 프로젝트에 Flake8 linting 단계를 추가하는 것으로 시작합니다.
빌드 단계를 성공적으로 만들었으면 다음 대화 상자가 표시됩니다.
다음으로, 프로젝트에 PyTest 단계를 추가해 보겠습니다.
이제 첫 빌드를 실행할 수 있습니다.
참고: TeamCity Cloud를 사용하는 경우 빌드 에이전트를 사용하려면 최대 2분 정도 기다려야 할 수 있습니다. 사용 가능한 에이전트에 의해 선택될 때까지 빌드가 당분간 대기열에 놓여집니다.
로컬 빌드 에이전트와 함께 TeamCity On-Premises를 사용하는 경우, 빌드가 즉시 시작됩니다.
빌드가 시작되면 빌드 개요 페이지로 이동하며, 이 페이지에서 빌드와 관련된 실시간 데이터를 표시하는 Build Log(빌드 로그)가 열립니다.
빌드가 실행되면 빌드의 개요 페이지로 리디렉션됩니다. 이제 테스트 결과 및 검사를 살펴보거나 빌드의 개요 페이지에서 전체 빌드 로그를 찾아 볼 수 있습니다.
이제 Python 저장소가 TeamCity에 연결되었으므로 코드를 계속 개발하고 저장소에 푸시할 수 있습니다.
기본적으로, TeamCity는 VCS 저장소의 메인 브랜치를 60초마다 폴링하여 수신한 변경 사항이 있는지 확인하고 탐지된 모든 커밋에 대해 하나의 (결합된) 빌드를 트리거합니다.
기본 브랜치뿐만 아니라 저장소의 모든 브랜치에 대한 모든 변경 사항에 대해 빌드를 트리거하려면 VCS 루트 설정에 와일드카드 브랜치 사양을 추가하세요. VCS 설정은 단일 빌드 구성이 아니라 TeamCity 프로젝트에 속합니다. 따라서 변경 사항은 동일한 VCS 루트를 사용하는 모든 빌드 구성에 적용됩니다.
브랜치 사양의 예:
+:refs/heads/*
– TeamCity는 프로젝트의 모든 브랜치에서 변경 사항을 확인하지만 refs/pull/*
와 일치하기 때문에 GitHub와 같은 플랫폼에서 풀 요청을 확인하지는 않습니다. +:*
– TeamCity는 모든 브랜치에서 수신되는 모든 변경 사항을 확인합니다. TeamCity는 이제 브랜치 사양을 따르고 저장소로 푸시되는 모든 브랜치를 모니터링하여 수신 변경 사항을 확인하고 그에 따라 빌드를 실행합니다.
TeamCity가 저장소에 대해 생성된 풀 요청을 자동으로 빌드하도록 하려면 빌드 구성에 풀 요청 빌드 기능을 추가할 수 있습니다.
참고: Pull Request(풀 요청) 빌드 기능은 브랜치 사양을 투명하게 확장합니다(자세한 내용은 이전 단계 참조). 예를 들어 GitHub의 경우 풀 요청 기능은 (보이지 않게) 브랜치 사양에 +:refs/pull/*
을 추가합니다.
풀 요청 기능을 사용할 때 풀 요청 브랜치가 일반 브랜치 사양에 포함되지 않도록 하는 것이 좋습니다. 그렇지 않으면 풀 요청 관련 기능을 TeamCity에서 사용할 수 없게 됩니다.
TeamCity는 이제 외부 플랫폼에서 풀 요청을 확인하고 구성 규칙과 일치하는 풀 요청에 대해 빌드를 트리거합니다.
참고: 빌드하려는 생각이 없는 저장소에 누군가가 유해한 코드를 푸시할 수 있으므로 공개 저장소에서는 이 기능을 주의해서 사용해야 합니다.
When using the pull requests feature in combination with Azure DevOps, Bitbucket Server, GitHub, or GitLab, it also makes sense to use the Commit Status Publisher build feature. 이 기능은 빌드 결과와 함께 해당 플랫폼에서 풀 요청의 상태를 업데이트합니다.
빌드 결과를 GitHub에 다시 보고하도록 TeamCity를 설정하려면 다음 단계를 따라야 합니다.
TeamCity가 빌드를 실행하면 이제 GitHub의 Pull Request(풀 요청) 탭(녹색 체크 표시)에서 변경 사항으로 인해 빌드에 실패했는지 여부를 쉽게 확인할 수 있습니다.