DevOps 메트릭으로 CI/CD 성능 측정

CI 서버 또는 '빌드 서버'는 VCS의 변경 사항 모니터링부터 새 빌드의 배포에 이르기까지 CI/CD 프로세스의 모든 단계를 조정합니다.

CI 서버를 사용하면 지속적 통합전달/배포(CI/CD) 프로세스를 간소화할 수 있습니다. CI 서버는 버전 관리 시스템(VCS)을 모니터링하고, 자동화된 빌드, 테스트 및 배포 작업을 트리거하고, 결과를 수집하고, 파이프라인의 다음 단계를 시작하는 역할을 합니다.

빌드 서버 없이도 CI/CD를 실행할 수는 있지만 많은 개발 팀은 프로세스를 조정하고 각 단계의 결과를 전달하는 데 CI 도구를 선택합니다. 이 가이드에서는 CI 서버가 어떤 일을 하고 CI/CD를 최대한 활용하는 데 어떤 도움을 줄 수 있는지 살펴봅니다.

CI 서버를 사용해야 하는 이유

CI 서버는 모든 CI/CD 활동을 조정하는 중심부입니다. CI 서버를 사용하면 다음과 같은 이점을 얻을 수 있습니다.

  • 모든 커밋이 CI/CD를 거치도록 보장: CI 서버는 VCS와 통합되어 모든 코드 변경 사항이 자동화된 빌드, 테스트 및 배포 프로세스를 거치도록 보장하므로 개별 개발자가 추가 작업을 수행할 필요가 없습니다.
  • 비즈니스 로직 조정: 적용하려는 테스트 커버리지 수준부터 자동화된 테스트 프로세스의 각 단계를 '통과'하기 위한 조건에 이르기까지 CI 서버는 조직의 요구 사항에 대한 단일 정보 소스를 제공합니다.
  • 툴체인과 통합: VCS와 빌드 도구 외에도 CI 서버는 이슈 트래커 및 커뮤니케이션 플랫폼과 통합되어 빌드, 테스트 및 배포 프로세스에서 자동화된 업데이트를 제공할 수 있습니다.
  • 과거 빌드 기록 유지: 빌드 아티팩트 아카이브는 특히 미묘한 버그가 코드베이스에 들어간 지점을 파악해야 할 때 매우 유용합니다.
  • 이해 관계자에게 릴리스 진행 상황에 대한 가시성 제공: CI 서버를 빌드 및 배포 상태에 대한 중앙 정보 소스로 사용하여 전체 조직에 진행 상황을 알려줄 수 있습니다.
  • 변경 사항에 대한 감사 로그 제공: 시간이 지남에 따라 워크플로와 비즈니스 로직은 진화하기 마련입니다. CI 서버를 사용하면 CI/CD 프로세스가 어떻게 변경되었는지에 대한 기록을 남길 수 있으므로 나중에 이전 구현으로 되돌리고 싶을 때 유용합니다.

결과적으로 CI 서버를 사용하면 코드 변경에 대한 신속한 피드백, 조기 버그 식별, 릴리스 주기 단축 등 CI/CD의 여러 이점을 누릴 수 있습니다.

CI/CD 서버를 사용해야 하는 이유

CI 서버의 작동 방식

정확한 프로세스는 팀과 조직의 요구 사항에 따라 다르지만 CI 서버는 일반적으로 다음 단계를 수행합니다.

  1. 버전 관리 시스템과 통합하여 관련 브랜치에 대한 커밋을 모니터링합니다.
  2. 변경 사항이 커밋될 때마다 일련의 빌드 및 테스트 작업을 시작합니다. 이러한 작업은 빌드 팜\\의 다른 시스템에 배포되거나 CI 서버 자체에서 실행됩니다.
  3. 이러한 작업의 결과를 정리하고 해당 데이터를 사용하여 프로세스의 다음 단계로 진행할지 여부를 결정합니다.
  4. 빌드 아티팩트를 중앙 아카이브에 저장합니다.
  5. 새로운 버전을 프로덕션에 배포합니다.
  6. 프로세스 전반에 걸쳐 피드백을 제공합니다.
CI 서버가 작동하는 방식

버전 관리 모니터링

모든 CI/CD 파이프라인의 시작 단계에 버전 또는 소스 관리 시스템과의 통합이 이루어집니다.

일반적으로 CI 서버는 특정 브랜치에서 커밋을 수신하고 변경이 이루어질 때마다 파이프라인의 새로운 실행을 트리거하도록 구성됩니다. 이를 통해 개발자가 변경 사항을 공유할 때마다 그 내용이 빌드되고 테스트되어 전체 코드베이스가 여전히 올바르게 작동하는지 확인할 수 있습니다.

일부 CI 서버에서는 한 단계 더 나아가 개발자가 CI 브랜치에 대한 변경 사항을 공유하기 전에 로컬에서 변경 사항을 빌드하고 테스트하도록 요구할 수 있습니다. 이것으로 다음 단계를 성공적으로 통과할 것이라는 보장은 없지만 손상된 빌드의 수와 이로 인해 발생할 수 있는 지연을 줄이는 데에는 도움이 됩니다. 또 다른 옵션은 CI 서버를 코드 검토 도구와 통합하여 각 커밋이 공유되기 전에 코드 검토 단계를 거치도록 하는 것입니다.

프로세스를 시작할 때 이러한 추가 계층의 비즈니스 로직을 적용하면 파이프라인의 방해와 지연을 최소화하면서 코드 베이스를 깨끗하게 유지하고 릴리스 준비를 갖추는 데 도움이 됩니다.

빌드 및 테스트 관리

변경 사항이 탐지되고 파이프라인 실행이 트리거될 때마다 CI 서버가 빌드 및 테스트 작업을 조정합니다. 일반적으로 이러한 작업은 전용 빌드 시스템 또는 '에이전트'에 할당됩니다. 그러면 빌드 에이전트는 CI 서버로부터 수신한 명령에 따라 빌드를 실행하고 테스트를 수행하는 어려운 작업을 처리합니다.

또 다른 옵션은 CI 서버 자체에서 빌드 및 테스트 작업을 실행하는 것입니다. 그러나 이로 인해 리소스 경합이 발생하고 처리량이 많은 코드베이스에서는 성능이 저하될 수 있습니다.

CI 서버를 사용하여 파이프라인의 단계를 위한 로직을 구성할 경우 다양한 세부사항과 규칙을 명시할 수 있습니다. 예를 들어 다음 작업을 수행하고 싶을 수 있습니다.

  • 메인 브랜치로 전송된 커밋에 대해 모든 자동화된 테스트를 실행하되, 피처 브랜치에서는 검사 수를 줄여서 실행합니다.
  • 테스트 데이터베이스를 동시에 호출할 수 있는 빌드의 수를 제어합니다.
  • 직접 개입하는 수동 테스트를 수행할 수 있도록 스테이징 환경에 대한 배포를 일주일에 한 번으로 제한합니다.

다양한 빌드 에이전트를 사용하여 특정 작업을 동시에 실행할 수 있다면 파이프라인의 효율을 높일 수 있습니다. 이는 다양한 운영 체제에서 테스트를 실행해야 하거나, 테스트 수가 수십만에 달하는 방대한 코드베이스에서 작업하고 병렬화가 유일한 옵션인 경우에 유용합니다. 후자의 경우, 복합 빌드를 설정하면 결과가 집계되어 작업을 하나의 빌드 단계로 처리할 수 있습니다.

AWS와 같이 클라우드로 호스팅되는 인프라와 통합된 빌드 서버는 빌드와 테스트를 실행하는 리소스의 탄력성과 확장성을 활용할 수 있게 해줍니다. 인프라 요구가 큰 경우, 컨테이너화된 빌드 에이전트를 지원하고 Kubernetes와 통합하면 클라우드 또는 온프레미스 여부에 관계없이 빌드 리소스를 효율적으로 관리할 수 있습니다.

합격 및 불합격 조건 정의

비즈니스 로직의 핵심 부분 중 하나는 CI/CD 파이프라인의 각 단계에 무엇이 실패(failure)를 구성하는지 정의하는 것입니다.

CI 서버에서는 다양한 실패 조건을 구성할 수 있습니다. CI 서버는 그 조건의 충족 여부를 기준으로 특정 단계의 상태를 확인하고 파이프라인의 다음 단계로 진행할지 판단합니다.

빌드가 오류를 반환하거나 테스트가 실행되지 않는 등의 자명한 실패 외에, 빌드 서버가 수집한 데이터를 토대로 다른 실패 조건을 정의할 수 있습니다.

일례로, 테스트 커버리지가 이전 빌드에 비해 감소하거나(최신 코드 변경에 대해 테스트가 추가되지 않은 것을 나타냄), 또는 무시된 테스트의 수가 마지막으로 성공한 빌드에 비해 증가하는 경우를 들 수 있습니다.

이러한 측정 기준은 코드 품질이 저하될 수 있는 경우에도 유용한 경고 역할을 합니다. 이러한 이유로 실패를 트리거하고 이러한 실패를 재정의할 수 있는 사용자를 제한함으로써 바람직한 동작을 촉진할 수 있습니다.

빌드 아티팩트 저장

변경이 성공적이면 CI 서버가 빌드 프로세스의 아티팩트를 저장합니다. 여기에는 소프트웨어를 배포하는 데 필요한 바이너리, 설치 프로그램, 컨테이너 이미지 및 기타 리소스가 포함될 수 있습니다.

그런 다음 최종적으로 프로덕션에 배포하기 전에 추가 테스트를 위해 동일한 아티팩트를 사전 프로덕션 환경에 배포할 수 있습니다. 이렇게 하면 모든 단계에서 동일한 출력을 테스트할 수 있고 배포 전에 매번 소스 코드를 다시 빌드하는 것보다 훨씬 더 안정적입니다. 특히, 종속성이 누락되거나 다른 불일치가 발생할 위험을 피할 수 있습니다.

성공적인 빌드의 아티팩트 저장소를 유지하면 이전 소프트웨어 버전으로 되돌려야 하거나 특정 문제가 발생한 시점을 확인해야 할 때도 유용합니다.

빌드 배포

'CI 서버'라는 이름만 보면 서버의 용도가 지속적 통합뿐인 것 같지만, 대부분의 CI 서버는 지속적 전달배포도 지원합니다.

지속적 통합 단계 중에 빌드 아티팩트를 생성하고 일련의 초기 테스트를 수행한 다음의 단계는 이러한 아티팩트를 QA 환경에 배포하여 추가 테스트를 수행하는 것입니다. 그 다음에는 스테이징 단계가 이어지는데, 여기서는 이해 관계자에게 새로운 빌드를 시험해 볼 기회가 제공됩니다. 그런 다음 모든 것이 제대로 작동하는 것 같으면 일반적으로 출시하게 됩니다.

CI 서버를 사용하면 파이프라인의 각 환경에 대한 매개변수를 저장하고 관리할 수 있습니다. 그러면 이전 단계의 결과를 토대로 배포 스크립트가 자동으로 트리거되는지 여부를 명시할 수 있습니다.

피드백 제공

CI 서버의 핵심적 기능은 빌드 및 테스트의 각 단계에 대한 신속한 피드백을 제공하는 것입니다. IDE 또는 커뮤니케이션 플랫폼과 통합된 CI 서버를 사용하면 변경 사항으로 인해 파이프라인에 장애가 생길 때마다 알림을 받을 수 있으므로 진행 상황을 지속적으로 모니터링할 필요가 없습니다.

빌드 서버로 다음과 같은 이점도 얻을 수 있습니다.

  • 진행 중인 빌드와 테스트에 대한 실시간 보고를 제공하고 완료된 빌드 단계의 상태를 알려줍니다.
  • 빌드 서버와 이슈 추적 도구를 통합하여 커밋에 포함된 수정 사항의 세부 내용을 확인하고 실패 원인을 빠르게 조사할 수 있습니다.
  • 배포 빈도, 다음 실패까지 걸리는 시간, 평균 해결 시간에 대한 통계를 수집하여 개발 프로세스를 측정하고 개선할 수 있습니다.
  • CI 서버와 빌드 시스템의 사용 및 성능 정보를 통해 파이프라인을 최적화할 수 있습니다.
빌드 서버의 이점

CI 서버를 직접 구축해야 할까요?

CI 서버를 직접 빌드하는 것은 매력적인 선택처럼 들릴 수 있습니다. 자체 솔루션을 설계하면 라이선스 비용을 피하면서 필요에 맞게 솔루션을 조정할 수 있습니다.

하지만 맞춤형 도구를 빌드하는 것은 긴 과정의 시작일 뿐입니다. 일단 배포한 후에는 최신 상태를 유지하기 위해 시간을 투자해야 합니다. 여기에는 발생하는 버그를 해결하고 요구 사항의 변화에 따라 새로운 기능을 개발하는 것도 포함됩니다.

CI 서버를 툴체인과 통합하는 데 필요한 노력도 생각해 보아야 할 수 있습니다. 초기 설계는 현재 사용 중인 버전 관리 시스템, 이슈 트래커, 빌드 도구 및 테스트 프레임워크와 호환되겠지만 새로운 제품이나 기술로 전환했을 때는 어떻게 될까요?

CI 서버를 직접 구축하면 사용 목적에 맞게 도구를 자유롭게 제작할 수는 있지만 초기에 노력과 지속적인 유지 관리가 필요하므로 상당한 시간과 노력이 필요합니다.

마무리

지속적 통합 서버는 CI/CD 파이프라인을 구현하고, 프로세스의 다양한 단계를 조율 및 트리거하며, 각 단계에서 데이터를 수집 및 전달하는 데 중요한 역할을 합니다. CI/CD 도구 가이드에서 조직에 적합한 CI 서버를 선택하는 방법에 대해 알아보세요.

TeamCity의 이점

TeamCity는 Git, Perforce, Mercurial, Subversion을 비롯한 모든 주요 버전 관리 시스템은 물론 다양한 호스팅 서비스와의 통합을 제공하는 CI 서버입니다. 또한 광범위한 빌드 도구와 테스트 프레임워크에 대한 광범위한 지원은 물론 IDE, 이슈 트래커, 메시징 플랫폼 및 컨테이너 관리자와의 통합도 제공됩니다.

CI 서버를 온프레미스 또는 원하는 클라우드에서 TeamCity Professional 또는 Enterprise로 호스팅하거나, 완전 관리형 솔루션인 TeamCity Cloud로 전환할 수 있습니다. 유연한 파이프라인 트리거 세트를 사용하면 사전 테스트된 커밋, 기능 브랜치 지원, 예약된 빌드를 비롯하여 요구 사항에 맞게 CI/CD 프로세스를 구성할 수 있습니다. UI를 통해 파이프라인 로직을 구성한 후에는 구성을 코드로 저장하여 완전한 버전 관리 CI/CD 프로세스를 구현할 수 있습니다.