인기 도구와 Jenkins 통합: 실용적 개요

Jenkins는 팀에서 이미 사용하는 도구(코드용 Git, 이미지용 Docker, 피드백용 테스트 프레임워크, 릴리스용 아티팩트 저장소)와 통신할 수 있을 때 유용해집니다. 목표는 찾을 수 있는 모든 플러그인을 설치하는 것이 아닙니다. 목표는 코드를 체크아웃하고, 빌드하고, 테스트하고, 결과를 게시하는 명확한 파이프라인을 구축하는 것입니다.

이 실용적인 개요는 Jenkins 통합이 일반적으로 어떻게 구성되는지와 팀이 자주 실수하는 부분을 보여줍니다.

소스 제어부터 시작

대부분의 Jenkins 파이프라인은 Git 체크아웃으로 시작합니다. Pipeline 작업에서 Jenkins는 작업에 구성된 저장소를 사용하여 checkout scm을 실행하거나 Jenkinsfile에서 저장소를 정의할 수 있습니다.

멀티브랜치 파이프라인의 경우 일반적으로 다음과 같이 충분합니다:

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
    }
}

멀티브랜치 작업은 설치 및 구성한 플러그인에 따라 GitHub, GitLab, Bitbucket 또는 기타 Git 서버에서 브랜치와 풀 리퀘스트를 검색합니다.

간단한 Pipeline 작업의 경우 명시적 체크아웃을 볼 수 있습니다:

git url: 'https://github.com/example/app.git', branch: 'main'

비공개 저장소에는 Jenkins 자격 증명을 사용하세요. 저장소 URL에 토큰을 넣지 마세요.

폴링보다 웹훅 선호

Jenkins는 변경 사항을 위해 Git을 폴링할 수 있지만 웹훅이 더 깔끔합니다. Git 제공자가 누군가 코드를 푸시하거나 풀 리퀘스트를 열 때 Jenkins에 요청을 보내면 Jenkins가 해당 작업을 시작합니다.

일반적인 설정은 다음과 같습니다:

GitHub Branch Source 또는 GitLab Branch Source와 같은 Git 제공자용 Jenkins 플러그인을 설치합니다.
멀티브랜치 Pipeline 작업을 생성합니다.
저장소 또는 조직 소스를 추가합니다.
Jenkins Credentials에 자격 증명을 저장합니다.
Git 제공자 설정에 웹훅 URL을 추가합니다.

폴링은 제한된 네트워크에서도 여전히 작동하지만 지연과 불필요한 부하를 추가합니다.

Docker 이미지 빌드 및 푸시

Jenkins는 빌드를 실행하는 에이전트에 Docker 액세스 권한이 있는 한 Docker 이미지를 빌드할 수 있습니다. Docker가 설치된 VM, Kaniko 또는 BuildKit과 같은 빌드 도구가 있는 Kubernetes 에이전트, 또는 제어된 Docker 소켓 설정일 수 있습니다.

다음은 간단한 Docker 빌드 및 푸시 흐름입니다:

pipeline {
    agent any

    environment {
        IMAGE = 'registry.example.com/team/app'
    }

    stages {
        stage('Build Image') {
            steps {
                sh 'docker build -t $IMAGE:$BUILD_NUMBER .'
            }
        }

        stage('Push Image') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'registry-login',
                    usernameVariable: 'REGISTRY_USER',
                    passwordVariable: 'REGISTRY_PASSWORD'
                )]) {
                    sh '''
                        echo "$REGISTRY_PASSWORD" | docker login registry.example.com \
                          --username "$REGISTRY_USER" --password-stdin
                        docker push "$IMAGE:$BUILD_NUMBER"
                    '''
                }
            }
        }
    }
}

중요한 세부 사항은 --password-stdin입니다. 명령줄에 레지스트리 비밀번호를 노출하지 않으며 docker login -p보다 안전합니다.

테스트 실행 및 결과 게시

Jenkins는 테스트를 실행하기 위해 테스트 프레임워크를 이해할 필요가 없습니다. Jenkins가 읽을 수 있는 보고서 형식을 생성하는 빌드 명령이 필요합니다.

JUnit 스타일 XML 보고서가 있는 Maven 프로젝트의 경우:

pipeline {
    agent any

    stages {
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
    }
}

post { always { ... } } 블록이 중요합니다. 테스트가 실패하더라도 테스트 결과를 게시하여 Jenkins UI에서 실패를 확인할 수 있습니다.

Python, JavaScript 및 Go 프로젝트는 호환되는 보고서를 생성하는 경우 동일한 패턴을 사용할 수 있습니다. 예를 들어 많은 Python 팀은 pytest --junitxml=reports/junit.xml을 실행한 다음 reports/junit.xml을 게시합니다.

아티팩트 저장소에 빌드 출력 저장

Jenkins 워크스페이스를 장기 저장소로 취급하지 마세요. 워크스페이스는 임시적이며 에이전트가 정리될 때 사라질 수 있습니다.

릴리스 출력에는 Nexus, Artifactory, 컨테이너 레지스트리 또는 클라우드 객체 스토리지와 같은 아티팩트 저장소를 사용하세요. Jenkins는 archiveArtifacts로 작은 진단 파일을 보관할 수 있지만 프로덕션 패키지는 보존 및 액세스 제어를 위해 설계된 시스템으로 보내야 합니다.

실행과 함께 빌드 로그 또는 보고서를 유지하는 예:

post {
    always {
        archiveArtifacts artifacts: 'reports/**', allowEmptyArchive: true
    }
}

이것을 빌드 증거로 사용하고 유일한 릴리스 저장소로 사용하지 마세요.

자격 증명을 파이프라인이 아닌 Jenkins에 보관

Jenkins Credentials는 사용자 이름, 비밀번호, SSH 키, 토큰 및 비밀 파일을 저장할 수 있습니다. 파이프라인은 비밀 값이 아닌 credentialsId를 참조해야 합니다.

셸 명령의 경우 필요한 단계 주변에서만 자격 증명을 바인딩하세요:

withCredentials([string(credentialsId: 'slack-webhook', variable: 'SLACK_WEBHOOK')]) {
    sh 'curl -X POST -H "Content-type: application/json" --data "{\"text\":\"Build complete\"}" "$SLACK_WEBHOOK"'
}

범위를 작게 유지하세요. 그러면 로그나 이후 명령을 통해 비밀이 유출될 가능성이 낮아집니다.

나중에 추가할 유용한 통합

핵심 파이프라인이 안정화되면 실제 워크플로우 요구 사항에 따라 통합을 추가하세요:

도구 유형	일반적인 용도
Git 제공자	브랜치 검색, 풀 리퀘스트 빌드, 커밋 상태 업데이트
Docker 또는 이미지 빌더	컨테이너 이미지 빌드 및 게시
테스트 보고	실패, 추세 및 불안정한 테스트 표시
아티팩트 저장소	빌드 출력 및 릴리스 패키지 저장
채팅 또는 인시던트 도구	실패하거나 릴리스된 빌드에 대해 적절한 채널에 알림
보안 스캐너	릴리스 전에 종속성, 이미지 또는 소스 코드 확인

한 번에 하나의 통합을 추가하고 파이프라인이 여전히 명확하게 실패하는지 확인하세요. 유용한 Jenkins 설정은 가장 좋은 의미에서 지루합니다. 개발자가 코드를 푸시하면 Jenkins가 빌드하고, 테스트하고, 아티팩트를 게시하고, 실패가 발생한 위치를 정확히 보여줍니다.