협업 소프트웨어 개발에서 코드 커밋 후 매번 수동으로 API 테스트를 실행하는 것은 빠르게 지루해질 수 있습니다. 새로운 코드가 푸시될 때마다 이러한 테스트가 자동으로 실행된다면 더 좋지 않을까요?
다행히도 이것은 전적으로 가능합니다. 대부분의 팀은 이미 코드 빌드 및 배포를 처리하기 위해 CI/CD 플랫폼을 사용하고 있으며, 이러한 플랫폼은 Git 커밋 이벤트를 수신하도록 설계되어 있습니다. 코드를 푸시하면 컴파일, 패키징 또는 배포와 같은 미리 정의된 작업을 자동으로 실행합니다.
자동화된 API 테스트 실행도 다르지 않습니다. Apidog는 단일 명령으로 자동화된 테스트를 트리거할 수 있는 CLI 도구를 제공합니다. 이 명령을 CI/CD 파이프라인에 추가하면 모든 코드 제출 후 테스트가 자동으로 실행되도록 할 수 있습니다.
설정 과정은 간단합니다. 핵심은 트리거 메커니즘이 어떻게 작동하는지 이해한 다음, 팀이 사용하는 플랫폼에 따라 올바른 통합 접근 방식을 선택하는 것입니다.
자동 테스트 트리거는 어떻게 작동할까요? (원리)
전체 프로세스의 핵심은 "이벤트 수신 + 명령 실행"입니다.
Git 저장소에 코드를 푸시하면 CI/CD 플랫폼은 이 Git 이벤트를 수신하고, 사전 설정된 구성(예: 파이프라인 스크립트 또는 구성 파일)에 따라 Apidog 테스트 명령을 자동으로 실행합니다.
이 원리는 다음과 같이 설명할 수 있습니다:
CI/CD 플랫폼이 Git 이벤트를 수신하는 방법은 주로 두 가지입니다:
첫 번째는 플랫폼의 내장 이벤트 메커니즘입니다. 예를 들어, GitHub Actions는 구성 파일에 `on: [push, pull_request]`와 같이 직접 지정할 수 있습니다. 코드를 푸시하거나 PR을 생성하면 플랫폼은 이러한 Git 이벤트를 자동으로 수신하고 테스트를 시작합니다.
두 번째는 Webhook을 통한 방법으로, Jenkins와 같이 플랫폼 간 통신이 필요한 시나리오에 적합합니다. 이 경우 트리거 URL을 수동으로 구성해야 합니다.
어떤 방법을 사용하든 마지막 단계는 항상 동일합니다: `apidog run` 명령을 실행하여 자동화된 테스트를 시작합니다.
인기 플랫폼을 위한 통합 솔루션
GitHub 또는 GitLab과 같은 코드 호스팅 플랫폼을 사용하는 경우 테스트 트리거링이 특히 간단합니다. 이러한 플랫폼에는 Git 이벤트를 직접 수신하고 작업을 실행할 수 있는 내장 CI/CD 서비스(예: GitHub Actions, GitLab CI)가 있습니다. 다음 문서를 참조하여 빠르게 시작할 수 있습니다:
그러나 많은 팀은 더 복잡한 설정을 가지고 있습니다. 예를 들어, 코드는 GitHub 또는 GitLab에 호스팅되지만 CI/CD 파이프라인은 Jenkins에서 실행됩니다. 이 경우 GitHub/GitLab과 Jenkins는 두 개의 독립적인 시스템이며, 전자는 후자를 직접 트리거할 수 없습니다.
크로스 플랫폼 시나리오의 경우 Webhook은 간단하고 효과적인 솔루션입니다. Webhook은 콜백 메커니즘처럼 작동합니다. GitHub에서 특정 이벤트(예: Git 푸시)가 발생하면 미리 정의된 Webhook URL로 요청을 적극적으로 보내 외부 시스템에 알립니다. Webhook 엔드포인트를 제공함으로써 Jenkins는 이러한 알림을 수신하고 테스트 작업을 자동으로 트리거할 수 있습니다.
특정 구성을 살펴보겠습니다: 코드는 GitHub에 호스팅되지만 테스트 파이프라인은 Jenkins에서 실행됩니다.
Apidog 자동화 테스트 실행을 위한 GitHub + Jenkins 통합
팀이 GitHub에 코드를 저장하지만 Jenkins를 사용하여 빌드 작업을 실행하는 경우 다음과 같이 설정할 수 있습니다:
1단계: Jenkins 구성 및 Webhook URL 확보
먼저 Jenkins에서 테스트 작업을 준비합니다. Jenkins와 통합 문서를 따라 프로젝트를 생성하고, 빌드 명령을 구성하며, CLI 명령이 제대로 실행되는지 확인합니다.
다음으로 Jenkins에서 Webhook URL을 가져옵니다. 이 URL은 외부 시스템이 Jenkins를 호출하기 위한 진입점 역할을 하며, GitHub는 이를 사용하여 테스트 작업을 트리거합니다.
가장 간단한 방법은 "Generic Webhook Trigger" 플러그인을 설치하는 것입니다. Jenkins의 플러그인 관리 페이지에서 검색하여 설치한 다음 Jenkins를 다시 시작합니다.
그런 다음 프로젝트의 구성 페이지로 이동하여 이 플러그인을 활성화합니다. Webhook 주소는 다음과 같습니다:
http://<your Jenkins server address>/generic-webhook-trigger/invoke`
보안을 위해 사용자 정의 토큰을 설정하는 것이 좋으며, 그러면 주소는 다음과 같이 됩니다:
http://<your Jenkins server address>/generic-webhook-trigger/invoke?token=<xxxxxx>이 URL을 확보한 후 GitHub에서 Webhook을 구성할 수 있습니다.
2단계: GitHub Webhook 구성
"GitHub 저장소 → Settings → Webhooks"로 이동하여 새 Webhook을 추가하고, 이전 단계에서 얻은 주소를 입력하고, Content type을 `application/json`으로 설정하고, 테스트를 트리거하려는 푸시 또는 기타 이벤트를 선택한 다음 구성을 저장합니다.
구성 후에는 모든 코드 푸시가 Jenkins를 자동으로 트리거하여 테스트 작업을 실행합니다. 일부 코드를 푸시하여 테스트하고 Jenkins 빌드 로그 및 테스트 결과를 확인할 수 있습니다.
3단계: 전체 프로세스 확인
GitHub에 코드를 푸시하면 구성된 Webhook이 Jenkins에 알림을 보냅니다. Jenkins는 요청을 수신하고 빌드 작업을 자동으로 시작합니다. Jenkins 프로젝트의 "Console"에서 테스트 실행 로그를 확인하고 최종 테스트 보고서를 볼 수 있습니다.
다른 플랫폼을 위한 Webhook 구성
GitHub 외에도 다른 코드 호스팅 플랫폼도 Webhook을 지원합니다. 예를 들면 다음과 같습니다:
구성 방법은 유사합니다. 핵심은 트리거 메커니즘을 이해하는 것입니다: Git 커밋이 이벤트를 생성하고, 이 이벤트는 이벤트 수신 또는 Webhook을 통해 CI/CD 플랫폼에 알림을 보내며, 궁극적으로 테스트 명령의 자동 실행을 트리거합니다.
더 많은 CI/CD 플랫폼 통합 방법은 Apidog 공식 문서의 CI/CD 통합 섹션을 참조하십시오.