[Jenkins] GitHub PR(Pull Request) 빌드 자동화 구축하기

현대의 소프트웨어 개발은 더 이상 혼자서 코드를 짜고 메인(main) 브랜치에 직접 푸시(Push)하는 방식으로 이루어지지 않습니다. 아무리 실력이 뛰어난 개발자라도 실수를 할 수 있기 때문에, 반드시 PR(Pull Request)을 올려서 동료들에게 코드 리뷰(Code Review)를 받고 안전하게 병합(Merge)하는 절차를 거칩니다. 그런데 리뷰어가 코드를 눈으로만 보고 "음, 버그는 없어 보이네요. LGTM(Looks Good To Me)!"이라고 승인했는데, 막상 머지하고 보니 컴파일 에러가 나거나 유닛 테스트가 박살 나는 경우가 비일비재합니다. 이를 방지하기 위해 "누군가 PR을 올리면 젠킨스가 미리 그 코드를 가져와서 몰래 빌드해 보고, 통과했을 때만 Github에 초록색 V(체크) 표시를 달아주는" 완벽한 협업 자동화 프로세스가 필요합니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 PR 빌드 자동화의 모든 것에 대하여 3,000자 분량으로 아주 치밀하게 딥다이브 해보겠습니다.

✅ 1. Github Status Checks (상태 검사)의 위력

Github 저장소 설정(Settings) -> Branches 메뉴에 가면 Branch Protection Rules (브랜치 보호 규칙)을 설정할 수 있습니다. 여기서 Require status checks to pass before merging 옵션을 켜면, 젠킨스(또는 다른 CI)가 빌드를 성공했다고 보고(Report)해 주기 전까지는 'Merge pull request' 버튼 자체가 비활성화(회색)되어 아무도 코드를 합칠 수 없게 됩니다. 불량 코드가 메인 브랜치로 유입되는 것을 시스템적으로 완벽하게 원천 차단하는 가장 훌륭한 장치입니다.

⚙️ 2. Jenkins 연동 셋업: Multibranch Pipeline 활용

이 기능을 구현하려면 17단계에서 배웠던 Multibranch Pipeline과 GitHub Branch Source Plugin의 조합이 필수적입니다.

1. Github Token 발급: 젠킨스가 Github API를 찔러서 상태를 변경하려면 권한이 필요합니다. Github에서 Personal Access Token(repo, admin:repo_hook 권한 포함)을 발급받아 젠킨스 Credentials에 Secret text로 등록합니다.

2. Multibranch Job 설정: 젠킨스에서 Multibranch Pipeline을 생성하고 Branch Sources에 Github을 추가합니다. 이때 Behaviors 항목에서 Discover pull requests from origin 옵션을 반드시 추가해야 합니다. (기본적으로 Merging the pull request with the current target branch revision 옵션을 선택하면, PR이 병합되었을 때의 미래 상태를 미리 젠킨스가 계산해서 빌드해 줍니다.)

💻 3. 실무 적용 극한의 Jenkinsfile 코드 파헤치기

일단 Multibranch가 셋업되면, 젠킨스는 누군가 PR을 올리는 즉시 이를 감지(Webhook)하고 파이프라인을 돌립니다. 파이프라인이 성공적으로 끝나거나 실패했을 때, 그 결과를 Github의 PR 화면으로 예쁘게 쏴주는 로직(Post Action)을 Jenkinsfile에 구성해야 합니다. (※ 최근 플러그인은 이 과정을 자동으로 해주기도 하지만, 명시적으로 커스텀 메시지를 쏘는 것이 실무의 정석입니다.)

pipeline {
    agent any
    stages {
        stage('Build & Test') {
            steps {
                echo "PR 코드를 빌드하고 테스트합니다..."
                sh 'npm ci'
                sh 'npm run test'
            }
        }
    }
    
    // 빌드가 완료된 후, 성공/실패 여부를 Github PR 화면으로 직접 콜백(Callback)합니다.
    post {
        success {
            // 플러그인 내장 함수(githubNotify)를 사용하여 Status를 PENDING -> SUCCESS 로 변경
            githubNotify context: 'Jenkins CI - Unit Test', 
                         status: 'SUCCESS', 
                         description: '🎉 모든 테스트가 통과했습니다! 안심하고 Merge 하세요.', 
                         targetUrl: "${env.BUILD_URL}"
        }
        failure {
            // 실패 시 PR 창에 빨간색 엑스 마크(FAILURE)와 함께 에러 원인 링크를 달아줍니다.
            githubNotify context: 'Jenkins CI - Unit Test', 
                         status: 'FAILURE', 
                         description: '🚨 빌드/테스트가 실패했습니다! Details 링크를 눌러 로그를 확인하세요.', 
                         targetUrl: "${env.BUILD_URL}console"
        }
    }
}

💡 4. 중급 꿀팁: PR과 일반 브랜치 분기 처리

Multibranch Pipeline 하나로 메인 브랜치 배포와 PR 검증을 동시에 처리하다 보면 문제가 생깁니다. PR이 올라왔을 때는 '빌드와 테스트'만 해야지, '실제 운영 서버 배포(Deploy)'까지 해버리면 큰일 나겠죠? env.CHANGE_ID 환경변수를 통해 현재 돌고 있는 파이프라인이 PR인지 아닌지를 식별할 수 있습니다.

stage('Production Deploy') {
    // env.CHANGE_ID가 없다는 것은 PR이 아니라 순수 브랜치(main)라는 뜻이므로 배포를 진행합니다.
    when {
        expression { return env.CHANGE_ID == null }
    }
    steps {
        echo "운영 서버로 상용 배포를 시작합니다!"
    }
}

🎯 5. 마무리 및 다음 단계

지금까지 동료의 눈에만 의존하던 불완전한 코드 리뷰 프로세스를, 젠킨스의 기계적인 테스트 빌드와 Github Status Checks 연동을 통해 완벽한 무결점 협업 프로세스로 승화시키는 마법에 대해 3,000자 분량으로 아주 치밀하게 다루어 보았습니다. 이제 리뷰어들은 젠킨스가 달아준 초록색 체크 마크를 확인한 뒤에만 가벼운 마음으로 코드를 살펴보면 됩니다.

자, 파이프라인의 구조와 협업 프로세스는 완벽해졌습니다. 그런데 최근 프론트엔드 팀에서 "A 프로젝트는 Node.js 14 버전을 써야 하고, B 프로젝트는 최신 Node.js 20 버전을 써야 하는데, 젠킨스 서버 하나에서 이거 두 개 동시에 빌드 가능해요?"라는 어려운 질문을 던졌습니다. 호스트 서버에 Node를 여러 개 깔아야 할까요? 이어지는 35단계 포스팅에서는 "원하는 버전의 환경을 파이프라인 안에서 마음대로 바꿔 끼우는 마술!" Node.js 다중 환경 파이프라인 구축 베스트 프랙티스에 대해 아주 꼼꼼하게 파헤쳐 보겠습니다!