TeamCity에서의 이전
TeamCity에서 GitLab CI/CD로 이전할 경우, TeamCity 워크플로우를 복제하고 향상시킬 수 있는 CI/CD 파이프라인을 생성할 수 있습니다.
주요 유사점 및 차이점
GitLab CI/CD와 TeamCity는 일부 유사한 점을 가진 CI/CD 도구입니다. GitLab과 TeamCity 모두:
- 대부분의 언어에 대한 작업을 유연하게 실행할 수 있습니다.
- 온프레미스 또는 클라우드에 배포될 수 있습니다.
또한 두 도구 간에 중요한 차이점이 있습니다:
- GitLab CI/CD 파이프라인은 YAML 형식의 구성 파일로 구성되며, 매뉴얼으로 편집하거나 파이프라인 편집기를 통해 편집할 수 있습니다. TeamCity 파이프라인은 UI에서 구성하거나 Kotlin DSL을 사용하여 구성할 수 있습니다.
- GitLab은 내장된 SCM, 컨테이너 레지스트리, 보안 스캐닝 등을 갖춘 DevSecOps 플랫폼입니다. TeamCity는 이러한 기능에 대한 별도 솔루션을 필요로 하며, 일반적으로 통합으로 제공됩니다.
구성 파일
TeamCity는 UI에서 구성하거나 Kotlin DSL 형식의 Teamcity Configuration 파일에서 구성할 수 있습니다.
TeamCity 빌드 구성은 소프트웨어 프로젝트를 빌드, 테스트 및 배포하는 방법을 정의하는 일련의 지침입니다.
이 구성에는 TeamCity에서 CI/CD 프로세스를 자동화하는 데 필요한 매개변수 및 설정이 포함됩니다.
GitLab에서는 TeamCity 빌드 구성과 동등한 것은 .gitlab-ci.yml 파일입니다.
이 파일은 프로젝트의 CI/CD 파이프라인을 정의하며, 프로젝트를 빌드, 테스트 및 배포하는 데 필요한 단계, 작업 및 명령을 지정합니다.
기능 및 개념 비교
많은 TeamCity 기능 및 개념은 동일한 기능을 제공하는 GitLab과 동등한 기능을 가지고 있습니다.
작업
TeamCity는 빌드 구성을 사용하며, 여기에는 코드를 컴파일하고 테스트를 실행하며 아티팩트를 패키징하는 작업을 정의하는 여러 빌드 단계로 구성됩니다.
다음은 Docker 파일을 빌드하고 단위 테스트를 실행하는 코틀린 DSL 형식의 TeamCity 프로젝트 구성 예시입니다:
// (이 부분은 번역되며 형식이 깨지지 않습니다.)
GitLab CI/CD에서는 파이프라인의 일부로 실행할 작업을 정의합니다. 각 작업에는 정의된 하나 이상의 빌드 단계가 있을 수 있습니다.
위 예시에 대한 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같을 것입니다:
// (이 부분은 번역되며 형식이 깨지지 않습니다.)
파이프라인 트리거
TeamCity 트리거는 VCS 변경, 예약된 트리거 또는 다른 빌드에 의해 트리거되는 등 빌드를 시작하는 조건을 정의합니다.
GitLab CI/CD에서는 파이프라인이 브랜치 또는 Merge Request의 변경, 새로운 태그와 같은 이벤트에 따라 자동으로 트리거되거나 API를 사용하거나 스케줄링된 파이프라인을 사용하여 수동으로 트리거될 수 있습니다. 더 많은 정보는 CI/CD 파이프라인을 참조하세요.
변수
TeamCity에서는 빌드 구성 설정에서 빌드 매개변수 및 환경 변수를 정의합니다.
GitLab에서는 variables 키워드를 사용하여 CI/CD 변수를 정의합니다.
변수를 사용하여 구성 데이터를 재사용하거나 더 동적인 구성 또는 중요한 값들을 저장합니다.
변수는 전역으로 또는 작업별로 정의할 수 있습니다.
예를 들어, 변수를 사용하는 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같을 것입니다:
// (이 부분은 번역되며 형식이 깨지지 않습니다.)
아티팩트
TeamCity의 빌드 구성은 빌드 프로세스 중에 생성된 아티팩트를 정의할 수 있습니다.
GitLab에서는 어떤 작업이 완료될 때 저장될 아티팩트들을 정의하기 위해 artifacts 키워드를 사용할 수 있습니다.
아티팩트는 테스트나 배포를 위해 나중에 사용될 수 있는 파일들입니다.
예를 들어, 아티팩트를 사용하는 GitLab CI/CD .gitlab-ci.yml 파일은 다음과 같을 것입니다:
// (이 부분은 번역되며 형식이 깨지지 않습니다.)
러너
GitLab에서 TeamCity 에이전트에 해당하는 것은 러너입니다.
GitLab CI/CD에서 러너는 작업을 실행하는 서비스입니다. GitLab.com을 사용 중이라면 별도의 Self-Managed 러너를 프로비저닝할 필요 없이 인스턴스 러너 플리트를 사용할 수 있습니다.
러너에 대한 주요 정보는 다음과 같습니다:
- 러너는 인스턴스, 그룹 또는 프로젝트에 특화하여 구성할 수 있습니다.
- 보다 정교한 제어를 위해
tags키워드를 사용하고 특정 작업에 러너를 연결할 수 있습니다. 예를 들어, 전용, 더 강력한 또는 특정 하드웨어가 필요한 작업에는 태그를 사용할 수 있습니다. - GitLab에는 러너용 자동 확장 기능이 있습니다. 필요할 때만 러너를 프로비저닝하고 필요하지 않을 때는 축소할 수 있습니다.
TeamCity 빌드 기능 및 플러그인
빌드 기능 및 플러그인을 통해 활성화된 일부 기능은 CI/CD 키워드 및 기능을 사용하여 GitLab CI/CD에서 기본적으로 지원됩니다.
| TeamCity 플러그인 | GitLab 기능 |
|---|---|
| 코드 커버리지 | 코드 커버리지 및 테스트 커버리지 시각화 |
| 단위 테스트 보고서 | JUnit 테스트 보고서 아티팩트 및 단위 테스트 보고서 |
| 알림 | 알림 이메일 및 Slack |
이주 계획 및 수행
다음은 GitLab CI/CD로의 신속한 이주를 완료한 조직을 관찰한 후에 생성된 권장 단계 디렉터리입니다.
이주 계획 작성
이주를 시작하기 전에 이주 계획을 작성하여 이주를 위한 준비를 해야 합니다.
TeamCity에서의 이주에 대한 준비로 다음 질문들을 스스로에게 물어보세요:
- 현재 TeamCity 작업에서 사용하는 플러그인은 무엇인가요?
- 이 플러그인들이 정확히 무엇을 하는지 알고 있나요?
- TeamCity 에이전트에 설치된 것은 무엇인가요?
- 사용 중인 공유 라이브러리가 있나요?
- TeamCity에서는 어떻게 인증을 하고 있나요? SSH 키, API 토큰 또는 다른 시크릿을 사용하고 있나요?
- 파이프라인에서 액세스해야 하는 다른 프로젝트가 있나요?
- TeamCity에 외부 서비스에 액세스하기 위한 자격 증명이 있나요? 예를 들어 Ansible Tower, Artifactory 또는 다른 클라우드 제공 업체 또는 배포 대상 등이 있나요?
선행 조건
이주 작업을 시작하기 전에 먼저 다음을 해야 합니다:
- GitLab을 알아봅니다.
- 주요 GitLab CI/CD 기능에 대해 읽어보세요.
- 첫 번째 GitLab 파이프라인 및 더 복잡한 파이프라인을 만들고, 정적 사이트를 빌드, 테스트 및 배포하는 튜토리얼을 따라보세요.
- CI/CD YAML 구문 참조를 검토하세요.
- GitLab을 설정하고 구성하세요.
- GitLab 인스턴스를 테스트하세요.
- 러너(runner)를 사용하거나 새 러너(runner)를 설치하여 사용 가능한지 확인하세요.
이주 단계
- SCM 솔루션에서 프로젝트를 GitLab로 이주하세요.
- (권장) 사용 가능한 이포터를 사용하여 외부 SCM 공급자로부터 자동으로 대규모를 이주할 수 있습니다.
- URL 별로 리포지터리를 가져오세요.
- 각 프로젝트에
.gitlab-ci.yml파일을 만드세요. - TeamCity 구성을 GitLab CI/CD 작업으로 이주하고, 합병 요청에서 결과를 직접 표시하도록 구성하세요.
- 클라우드 배포 템플릿, 환경 및 Kubernetes용 GitLab 에이전트을 사용하여 배포 작업을 이주하세요.
- 서로 다른 프로젝트 간에 재사용할 수 있는 CI/CD 구성이 있는지 확인한 후, CI/CD 템플릿 또는 CI/CD 컴포넌트를 만들고 공유하세요.
- GitLab CI/CD 파이프라인을 더 빠르고 효율적으로 만드는 방법에 대해 파이프라인 효율성를 참조하세요.
여기에 답변되지 않은 질문이 있다면, GitLab 커뮤니티 포럼을 참고하세요.
도움말