CI 서버란?

At the start of any CI/CD pipeline is an integration with your version or source control system.

기본 구현에는 마스터 브랜치의 커밋을 수신 대기하도록 CI/CD 서버를 구성하고 변경이 이루어질 경우 파이프라인을 트리거하는 작업이 수반됩니다.

이는 각 커밋을 확인 및 테스트할 수 있도록 보장하는 한편, 개인들이 빌드를 중단하는 무언가를 커밋하여 오류 코드가 백 아웃(back out)되거나 수정될 때까지 프로세스를 중단시키고 다른 변경 내용이 확인되는 것을 방지할 수 있는 충분한 여지를 남깁니다.

변경 내용이 커밋되기 전에 빌드 및 테스트하도록 CI 서버를 구성하면 이러한 유형의 이슈를 방지하는 데 도움이 되고 각 개발자를 위한 추가적 피드백 루프가 생성됩니다.

빌드 서버는 인에이블러(enabler)와 인포서(enforcer)의 역할을 동시에 수행합니다. 원격 시스템에서 빌드 및 테스트의 실행을 관리하고 결과를 개인들에게 피드백할 뿐 아니라, 해당 프로세스를 마스터 또는 기능 브랜치에 커밋하는 조건으로 만듭니다.

고려해야 할 또 한 가지 단계는 CI 서버를 코드 검토 도구와 통합하여 각 커밋이 코드 검토를, 그것이 커밋되기 전에 그러나 성공적으로 빌드 및 테스트된 후에만, 통과하도록 하는 것이다.

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

CI/CD 파이프라인의 빌드 및 테스트 단계에서, CI 서버는 운영의 수뇌부로서 작업을 조율하고 다양한 기준에 따라 빌드 에이전트에 작업을 할당합니다.

하지만 빌드 에이전트는 CI 서버로부터 수신한 명령에 따라 빌드를 실행하고 테스트를 수행하는 어려운 작업을 처리합니다.

리소스 경합과 성능 문제를 방지하기 위해 적어도 프로덕션 설정에서는 빌드를 실행하고 테스트를 수행하는 빌드 에이전트로부터 빌드 서버를 분리하는 것이 바람직합니다.

CI 서버를 사용하여 파이프라인의 단계를 위한 로직을 구성할 경우 다양한 세부사항과 규칙을 명시할 수 있습니다. 예를 들어, 개발 브랜치에서 프리커밋을 실행할 경우를 제외하고 마스터 브랜치의 커밋에 대해 특정 테스트를 수행하거나, 또는 동시에 테스트 데이터베이스를 호출할 수 있는 빌드의 수를 제어하고자 할 수 있습니다.

다양한 빌드 에이전트를 사용하여 특정 작업을 동시에 실행할 수 있다면 파이프라인의 효율을 높일 수 있습니다. 이는 다양한 운영 체제에서 테스트를 실행해야 하거나, 테스트 수가 수십만에 달하는 방대한 코드 베이스에서 작업하고 병렬화하가 유일한 옵션인 경우에 유용합니다. In the latter case, setting up a composite build will aggregate the results so you can treat the tasks as a single build step.

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

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

Your CI server should allow you to configure various failure conditions, which it will then apply and use to determine the status of a particular step and whether to proceed to the next stage of the pipeline.

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

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

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

"CI 서버"라는 명칭은 지속적 통합으로 사용이 제한된다는 것을 시사하지만, 대부분의 CI 서버는 또한 지속적 전달 및 배포를 지원합니다.

지속적 통합 단계 중에 빌드 아티팩트를 생성하고 일련의 초기 테스트를 수행한 다음의 단계는 이러한 아티팩트를 QA 환경에 배포하여 좀더 높은 수준의 테스트와 스테이징을 수행하는 것입니다. 관계자들은 이를 직접 사용해 보고 아무런 문제가 없으면 라이브 릴리스할 수 있습니다.

As well as providing an artifact repository to store the outputs from each build so you can deploy them as needed, a CI/CD server can also store and manage parameters for each environment in your pipeline. 그런 다음 이전 단계의 결과를 토대로 배포 스크립트가 자동으로 트리거되는지 여부를 명시할 수 있습니다.

각 단계마다 신속한 피드백을 제공하는 것은 CI/CD 파이프라인의 핵심 요소입니다.

빌드 서버는 대기 중인 작업, 진행 중인 빌드 및 테스트에 관한 실시간 보고, 완료된 빌드 단계의 상태 등에 관한 정보를 제공할 수 있습니다.

알림을 사용하면 문제가 발생하는 즉시 인지할 수 있으며, 버그 추적 도구와 통합하면 커밋에 포함된 수정의 세부정보를 확인하고 실패의 원인을 신속히 분석할 수 있습니다. 과거 데이터는 파이프라인을 개선하고 파이프라인 로직의 일부로 조건을 정의하는 데 유용한 인사이트를 제공할 수 있습니다.

지속적 통합 서버는 CI/CD 파이프라인을 구현하고, 프로세스의 다양한 단계를 조율 및 트리거하며, 각 단계에서 데이터를 수집 및 전달하는 데 중요한 역할을 합니다. Have a look at our Guide to CI/CD tools for tips on how to choose the right CI server for your organization.