Picnic

TeamCity 채택 전에 해결해야 할 과제

이전에 어떤 CI/CD 제품을 사용했고 새로운 제품을 찾게 된 이유는 무엇인가요?

이전 CI 솔루션에 확장이 요구되면서 2021년 말 JetBrains TeamCity로 눈을 돌리기 시작했습니다. 당시에 느린 빌드 시간과 긴 빌드 대기열이라는 두 가지 고충이 있었습니다. 피크 시간에는 일부 빌드가 실행되기까지 최대 1시간 동안 대기열에 남아 있기도 했습니다.

이전 솔루션 내에서 이 상황을 해결하기 위한 주된 접근 방식은 빌드 에이전트의 수와 크기를 크게 늘려 총 빌드 시간을 줄이는 것이었습니다. 그러나 이 솔루션은 빌드 속도의 핵심적 문제를 해결하지 않았기 때문에 확장할 수 없었습니다. 그래서 이 작업을 더 빠르고 원활하게 수행할 수 있는 새로운 솔루션을 찾기로 결정했습니다.

저희는 사용 중이던 CI 솔루션을 대체하기 위해 전체 기술 스택을 지원하고 애플리케이션을 빌드하고 테스트하는 방식을 표준화할 수 있는 시스템을 찾고 있었습니다. 백엔드 애플리케이션 개발에는 Java 및 Python이 사용되고 VCS로 GitHub가 사용되며 모바일 개발에는 Kotlin, Swift 및 React Native가 사용됩니다.

대체 솔루션으로 무엇을 고려했나요? CI/CD 도구에 대한 주요 기준은 무엇인가요?

처음에는 잠재적인 솔루션 공급자로 10곳을 생각했는데 이후 CircleCI, TeamCity 및 GitHub Actions의 3개로 줄였습니다. 주요 목표는 대기 시간을 최소화하고 빌드 시간을 단축하여 CI 성능을 개선하는 것이었습니다.

또 다른 요구 사항은 자체 호스팅 에이전트를 보유하는 것이었습니다. 분석 중에 확인해 보니, 이전 솔루션은 에이전트의 도구를 그렇게 빨리 업그레이드하지 않았습니다. 빌드할 때마다 도구 설치에 2~5분이 걸렸습니다. 평균 빌드 시간이 약 9분이라는 점을 감안하면 도구를 사전에 설치하는 데 3분이 추가로 소요된다는 것은 말이 되지 않습니다. 이 때문에 최신 도구, 적절한 성능, 그리고 빌드를 시작하는 데 필요한 거의 모든 요소를 갖춘 자체 호스팅 에이전트를 마련하자는 생각이 들었습니다.

클라우드에 배치된 CI 솔루션도 저희에게 필요한 전제 조건이었습니다. Picnic에서는 최대한 적은 수의 시스템을 관리하려고 합니다. CI를 통해 직접 실행할 필요가 없는 관리형 솔루션을 구현하면, 동시에 클라우드의 자체 호스팅 에이전트를 통해 실행 중인 소프트웨어와 사용 중인 정확한 도구를 관리하게 됩니다. 이렇게 하면 CI 서버를 관리할 필요 없이 전체 빌드 환경(사용 중인 하드웨어와 사전 설치된 정확한 도구)을 제어할 수 있는 유연성이 생깁니다.

정량 및 CI/CD 메트릭

저희는 약 300명의 CI 사용자를 보유하고 있으며, 이 중 대부분이 활동적이고 거의 200개 프로젝트에 집중적으로 참여하고 있습니다. 이러한 프로젝트는 120개 이상의 VCS 루트가 있는 TeamCity의 탄탄한 계층 구조를 따릅니다.

저희는 최대 40개의 동시 빌드를 위한 40개의 빌드 에이전트를 가지고 있습니다. 하루에 거의 1,100개의 빌드를 실행하며 하루 총 빌드 시간만 거의 10,000분에 달합니다. 에이전트가 작동하는 데에는 약 2분이 필요하며 빌드가 이보다 더 오래 대기하는 경우는 거의 없습니다.

이 모든 작업의 한 달간 총 빌드 시간은 약 300,000분에 달합니다.

개발 프로세스의 어떤 부분을 TeamCity가 지원하나요?

내부 개발에는 항상 TeamCity를 사용합니다. GitHub에서 PR을 열면 CI가 이를 빌드하고 유닛, 통합 및 구성 요소 테스트를 실행한 다음 피드백을 제공합니다. 보통은 여기서 끝납니다. TeamCity는 빌드 아티팩트를 생성하고 이후 배포를 위해 이를 저장소로 푸시하는 단계까지 진행됩니다.

무엇을, 어떻게, 어디에 배포하나요?

모든 Linux 및 일반 빌드 에이전트는 클라우드 공급자인 AWS에서 실행됩니다. iOS 애플리케이션의 경우, 사무실의 네트워크와 TeamCity에 연결된 몇 대의 Mac mini가 있습니다. 사실 iOS 팀은 TeamCity Cloud로 마이그레이션하기 전부터 현장에서 TeamCity를 사용하고 있었습니다.

에이전트가 주문형 인스턴스로 실행됩니다. 스팟 인스턴스는 향후 개선의 여지가 있는 여전히 매우 매력적인 옵션입니다.

저희는 자체 이미지를 준비하고 TeamCity 클라우드 프로파일을 사용하여 자체 호스팅 에이전트를 실행합니다. 사실 이것들은 AWS의 EC2 머신입니다. 에이전트의 AWS 이미지를 빌드하는 데 TeamCity와 Packer가 사용됩니다.

그런 다음 이러한 에이전트를 TeamCity의 실행 템플릿 및 클라우드 프로파일과 함께 사용하여 필요에 따라 빌드 에이전트를 시작합니다. 이 에이전트는 현재 수명이 짧고 단일 빌드에만 사용됩니다.

대기열 시간은 2분이고 그 중 1.5분은 빌드 에이전트가 AWS에서 프로비저닝되기를 기다리는 시간인 것으로 확인되었습니다. 수명이 긴 재사용 가능한 에이전트를 사용하면 이 문제를 해소하는 데 도움이 됩니다. 이를 통해 스팟 인스턴스를 살펴볼 수 있습니다.

코드 또는 Kotlin DSL로 구성을 사용하시나요? 그렇다면 이에 대한 접근 방식은 무엇인가요?

저희는 정책으로 TeamCity의 UI에서 편집을 금지하고 있습니다. 목표 중 하나는 파이프라인을 표준화하는 것이고, 이를 위해 구성을 코드로 사용하는 방법을 채택하고 있습니다.

모든 빌드 구성은 해당 저장소에 Kotlin 코드로 저장됩니다. TeamCity Kotlin DSL 위에 자체 DSL을 빌드했기 때문에 20줄 미만의 코드로 파이프라인을 정의할 수 있습니다.

예를 들어 Java 애플리케이션을 빌드하는 기본 빌드를 얻을 수 있습니다. 여기서 모든 테스트와 구성 요소 테스트가 실행됩니다. 모든 것이 성공하면 빌드 아티팩트가 적절한 저장소에 업로드됩니다.

그 외에도 코드의 정적 분석을 위한 별도의 잡(Job)과 SonarCloud에서 사용할 코드의 야간 정적 분석을 위한 잡이 하나 더 있습니다. 이는 모두 표준 파이프라인의 일부입니다. Java 애플리케이션의 경우 파이프라인의 기본 사항만 정의하면 처음부터 이용할 수 있습니다.

어떤 팀은 구성 요소 테스트(BDD)를 많이 수행합니다. Python으로 작성하지만 기본 앱은 Java로 작성합니다. 앱은 Docker 이미지로 패키지 처리합니다. 그런 다음 실제 인프라(데이터베이스 등)가 있는 빌드 에이전트에서 Docker Compose 환경을 가동하고, 타사 서비스는 모의 객체화합니다. Docker Compose에서 실행되는 앱에 대해서는 Behave 테스트를 실행합니다.

TeamCity에서 제공하는 Kotlin DSL에서 빌드 파이프라인에 대해 원하는 모든 조정을 수행할 수 있습니다. 스텝, 트리거 및 기타 여러 항목을 변경할 수 있습니다.

기본적으로 팀에는 플랫폼 팀의 관점을 기준으로 한 황금 표준의 파이프라인이 제공됩니다. 예를 들어 동일한 잡의 일부로서, 동일한 에이전트에서 빌드 파이프라인의 일부로서 구성 요소 테스트가 실행됩니다.

불행히도 아직 병렬화되지 않은 수백 개의 구성 요소 테스트를 수행해야 하는 팀이 있습니다. 이러한 경우 Behave 구성 요소 테스트를 테스트 스위트로 분할하고 이를 빌드 체인으로 구성할 수 있습니다.

기본 빌드는 아티팩트를 생성하고 유닛 테스트와 간단한 신속 테스트를 실행합니다. 테스트가 성공하면 서로 다른 에이전트에서 여러 인스턴스로 테스트하는 병렬 테스트 모음을 필요한 만큼 실행할 수 있습니다.

TeamCity를 사용할 때의 가장 큰 이점과 단점은 무엇인가요?

다음은 TeamCity 사용과 관련하여 가장 마음에 드는 점입니다.

디폴트 빌드 에이전트 설정. TeamCity를 처음 살펴보면서 이 시스템이 SSD가 연결된 컴퓨팅 최적화 에이전트를 사용한다는 사실을 알아챘습니다. 이 에이전트 덕에 다른 CI에 비해 최고의 성능을 발휘하죠. 저희는 제공된 에이전트를 사용하지는 않지만 여기에서 힌트를 얻어 자체 에이전트에 컴퓨팅 최적화 인스턴스를 사용해 더 나은 성능을 제공할 수 있었습니다.

성능 모니터링 기능도 좋아합니다. 이러한 파이프라인을 사용하는 실제 팀이 직면한 가장 큰 어려움 중 하나는 큰 인스턴스, 중간 인스턴스 또는 큰 인스턴스 중 어떤 것을 사용할지 결정하는 것입니다. 성능 모니터링을 확인하면 이에 대한 훌륭한 인사이트를 얻을 수 있습니다. 그러면 디버그 처리가 간단해집니다.

안타깝게도 현재 TeamCity는 프로젝트별로만 메트릭을 제공하기 때문에 TeamCity에서 빌드하고 있는 프로젝트 전체에 대한 정보를 얻기는 힘들지만 그렇게만 된다면 매우 좋을 것입니다. 예를 들어 지금은 모든 Java 프로젝트의 메트릭을 볼 수 있는 방법이 없습니다.

또한 Kotlin DSL은 특히 Java에 익숙하지 않은 엔지니어의 경우에 학습 곡선이 상당히 가파릅니다.

향후 계획

이제 모든 프로젝트를 TeamCity로 마이그레이션했으므로 빌드 에이전트, 스팟 인스턴스 등을 추가로 실험하려고 합니다.

이를 원활하게 수행하기 위해 저희는 체계적인 방식으로 빌드 메트릭을 캡처하는 것을 좋아합니다. 이러한 모든 메트릭은 TeamCity에서 사용할 수 있습니다. 앞으로 해결해야 할 과제는 모든 프로젝트에서 이러한 메트릭을 확인하고 시간이 지남에 따라 어떻게 전개되는지 볼 수 있는 방법을 찾는 것입니다.

이 정보를 활용하면 먼저 무엇을 개선하고 집중해야 하는지, 조정으로 성능이 어떤 식으로 개선 또는 저하될지 등, 최적화를 향상하기 위한 결정을 내릴 수 있습니다. 현재 저희는 외부 서비스를 빌드하여 이 모든 정보를 집계해 보려고 생각 중입니다. 바로 이용할 수 있는 서비스가 있다면 훨씬 더 좋겠죠!

또한 최적화의 가능성을 모색하고 수명이 긴 에이전트를 사용하거나 사전 준비 상태의 에이전트 풀을 도입하여 에이전트 시작 시간에 소요되는 추가 시간을 없애기 위한 노력을 기울일 예정입니다.

Picnic에서 진행 중인 또 다른 작업은 더 많은 엔드투엔드 테스트를 빌드하는 것입니다. 이는 TeamCity에서 실행되는 또 다른 프로젝트가 될 것입니다. 그 다음에는 CI/CD를 완전히 TeamCity로 옮길지 여부를 새롭게 검토해야 합니다.