SCM Polling(소스 코드 관리 폴링)은 CI/CD 서버(예: Jenkins)가 저장소(SCM: Git, Subversion 등)를 주기적으로 조회해서 변경사항(새 커밋, 새 리비전 등)이 있는지 확인하고, 변경이 있으면 빌드나 파이프라인을 트리거하는 방식입니다. 푸시 기반 트리거(웹훅)와 달리, 저장소가 서버로 정보를 보내지 않고 CI 쪽에서 주기적으로 묻는(폴링하는) 방식입니다. 주요 동작 방식 - 스케줄(예: cron 표현식)에 따라 CI 서버가 지정된 주기로 원격 저장소를 확인한다. - 확인 방법은 SCM 유형에 따라 다르다. - Git: 원격의 참조나 HEAD 해시를 조회(예: git ls-remote)하거나 원격 브랜치의 최신 커밋 해시를 로컬 기록과 비교. - Subversion: 최신 리비전 번호(svn info 또는 svnlook)를 조회해 마지막 빌드 시점과 비교. - 원격과 로컬(또는 마지막 빌드 시점)에 차이가 있으면 빌드를 실행한다. 차이가 없으면 아무 작업도 하지 않음. 장점 - 구현이 간단하고 저장소 쪽 설정이 필요없음(웹훅을 지원하지 않는 환경에서도 동작). - 방화벽, 네트워크 정책 등으로 인해 외부에서 접속이 제한된 환경에서 유용. 단점 - 지연: 폴링 간격만큼 트리거 지연이 발생(예: 폴링 5분이면 최대 5분 지연). - 부하: 짧은 간격으로 여러 프로젝트를 폴링하면 SCM 서버/네트워크 부하가 커짐. - 비효율성: 변경이 자주 없을 때에도 주기적으로 쓸데없이 조회함. - 정확성 문제: 폴링 시점과 실제 커밋 타이밍에 따른 레이스 컨디션이 있을 수 있음(특히 복수 브랜치/머지 상황). Jenkins에서의 예(참고용) - "Poll SCM" 옵션에 cron 스타일 스케줄을 입력(예: H/5 * * * * 는 5분마다). - Jenkins는 폴링 시 원격 리포지토의 최신 리비전을 확인하고, 마지막 빌드의 리비전과 다르면 빌드를 시작. - 멀티브랜치 파이프라인의 경우 브랜치 인덱싱과 병행되어 동작하며, 브랜치 탐지에도 폴링을 사용 가능. 모범 사례 - 가능하면 웹훅(푸시 트리거)을 사용해 지연과 불필요한 부하를 줄임. - 폴링 사용 시 간격을 과도하게 짧게 설정하지 않음(예: 최소 수분 단위). - 저장소별로 폴링을 분산하거나 시차를 두어 SCM 서버 부하를 완화함. - 폴링 시 특정 경로만 감시하거나 변경파일 필터링을 사용해 불필요한 빌드를 줄임. - 대규모 환경에서는 중앙 캐시나 전용 인덱서 도입을 고려. 간단 예시 - Jenkins 스케줄: H/10 * * * * → 10분마다 폴링. - Git 폴링 내부 동작: 원격 HEAD 해시 조회 → 마지막 빌드 해시와 비교 → 다르면 git fetch 후 빌드. 요약하면, SCM Polling은 CI가 주기적으로 SCM을 조회해 변경을 감지하여 빌드를 트리거하는 방식으로, 구현은 간단하지만 지연·부하 측면의 단점이 있어 가능한 경우 웹훅 같은 푸시 기반 트리거를 권장합니다.
