우리는 종종 UI만을 사용하여 Jenkins 작업을 생성하였습니다. 이후 빌드 및 배포 작업의 복잡성이 증가함에 따라 ‘파이프라인을 코드로 다루기’라는 아이디어가 제시되었습니다. Jenkins 2.0에서 Jenkins 팀은 ‘파이프라인을 코드로 다루기’를 달성하기 위해 Jenkinsfile을 도입하였습니다. 자동화된 풀 리퀘스트 기반 또는 브랜치 기반의 Jenkins 지속적 통합 및 지속적 전달 파이프라인을 생성하고자 한다면, Jenkins 멀티브랜치 파이프라인이 방법입니다.
Jenkins 멀티브랜치 파이프라인은 완전히 git 기반의 파이프라인 코드이므로 CI/CD 워크플로우를 구축할 수 있습니다. 파이프라인 코드(PaaC)를 사용하면 자동화와 클라우드 이식성의 장점을 Selenium에 쉽게 적용할 수 있습니다. 멀티브랜치 파이프라인 모델을 사용하여 신속하고 안정적으로 빌드, 테스트, 배포, 모니터링, 보고 및 관리하여 Selenium 테스트를 수행할 수 있습니다. 이 Jenkins 튜토리얼에서는 Jenkins 멀티브랜치 파이프라인을 생성하는 방법과 Selenium 자동화 테스트를 위한 Jenkins 멀티브랜치 파이프라인을 구성하는 데 관련된 주요 개념을 살펴보겠습니다.
시작하겠습니다.
Jenkins 멀티브랜치 파이프라인이란?
공식 문서에 따르면, 멀티브랜치 파이프라인 작업 유형을 정의하여 단일 git 리포지토리에서 Jenkins가 여러 브랜치를 감지하고 Jenkinsfile을 찾을 때마다 중첩된 작업을 생성하는 작업을 정의할 수 있습니다.
위의 정의에서 우리는 이해할 수 있듯이, Jenkins는 Git 저장소를 검사하여 Jenkinsfile을 찾아 자동으로 작업을 생성할 수 있습니다. 우리로부터 필요로 하는 것은 Git 저장소 세부 정보입니다. 이 기사에서는 샘플 GitHub 저장소를 사용할 것입니다. 우리의 샘플 GitHub 저장소에는 Tomcat에 배포할 수 있는 샘플 Spring Boot 프로젝트가 포함되어 있습니다.
프로젝트의 루트 디렉토리에는 Jenkinsfile이 있습니다. 이 Jenkinsfile은 Jenkins 선언적 파이프라인 구문을 사용하여 작성되었습니다. Jenkins 선언적 파이프라인에 익숙하지 않다면 자세한 내용을 읽어보세요 여기.
샘플 Jenkinsfile
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}우리는 Jenkinsfile에 “코드 빌드”와 “코드 배포”라는 두 단계를 만들어 각각 적절한 메시지를 출력하도록 구성했습니다. 이제 Git 저장소와 Jenkinsfile이 준비되었습니다.
Jenkins 서버에서 Jenkins 멀티브랜치 파이프라인을 생성해 보겠습니다.
Jenkins 파이프라인과 멀티브랜치 파이프라인
Jenkins 파이프라인은 새롭고 뜨거운 것이지만 모두를 위한 것은 아닙니다. 그리고 멀티브랜치 파이프라인은 여전히 굉장합니다. 이 Jenkins 멀티브랜치 파이프라인 튜토리얼의 이 섹션에서 Jenkins 파이프라인과 멀티브랜치 파이프라인의 이상적인 사용 사례를 Jenkins 파이프라인과 멀티브랜치 파이프라인 비교를 통해 이해해 보겠습니다.
Jenkins 파이프라인은 작업 구성 시스템으로, 당신을 대신하여 자동으로 실행되는 작업의 파이프라인을 구성할 수 있게 해줍니다. Jenkins 파이프라인은 여러 단계를 가질 수 있으며, 각 단계는 단일 에이전트에 의해 실행되며, 이 모든 작업이 단일 머신 또는 여러 머신에서 실행됩니다. 파이프라인은 일반적으로 소스 코드의 특정 브랜치를 위해 생성됩니다. 새 작업을 생성할 때, 소스 코드 저장소와 브랜치를 선택하는 옵션을 볼 수 있습니다. 또한 기존 프로젝트의 새 프로젝트나 새 기능에 대한 새로운 파이프라인을 만들 수도 있습니다.
Jenkins 파이프라인을 사용하면 빌드를 위한 단계를 가진 유연한 Jenkinsfile을 가질 수 있습니다. 따라서 린팅, 테스트 등을 실행하는 초기 단계와 아티팩트를 빌드하거나 배포하는 별도의 단계를 가질 수 있습니다. 파이프라인에서 여러 작업을 수행하려는 경우 매우 유용합니다.
하지만 단 한 가지 작업만 해야 한다면 어떨까요? 아니면 원하는 모든 작업이 어떤 구성에 따라 달라진다면요? 이런 경우에도 Jenkins 파이프라인을 사용하는 것이 의미가 있을까요?
다중 브랜치 파이프라인은 이러한 경우에 더 적합할 수 있는 대안적인 접근 방식입니다. 다중 브랜치 파이프라인을 사용하면 작업을 브랜치로 분할하여 나중에 합칠 수 있습니다. 이는 Git 브랜칭 방식과 매우 유사합니다.
A multibranch pipeline is a pipeline that has multiple branches. The main advantage of using a multibranch pipeline is to build and deploy multiple branches from a single repository. Having a multibranch pipeline also allows you to have different environments for different branches. However, it is not recommended to use a multibranch pipeline if you do not have a standard branching and CI/CD strategy.
이제 Jenkins 파이프라인과 다중 브랜치 파이프라인의 비교를 살펴보았으니, Jenkins 다중 브랜치 파이프라인을 생성하는 단계를 살펴보겠습니다.
Jenkins 다중 브랜치 파이프라인 생성
Step 1
로컬에서 Jenkins 홈 페이지(http://localhost:8080)를 열고 왼쪽 사이드 메뉴에서 “새 항목”을 클릭하세요.
2단계
입력 Jenkins 작업 이름, 스타일을 “다중 브랜치 파이프라인”으로 선택하고 “확인”을 클릭합니다.
3단계
“구성” 페이지에서 우리는 한 가지만 구성해야 합니다: Git 리포지토리 소스.
“브랜치 소스” 섹션으로 스크롤하여 “소스 추가” 드롭다운을 클릭합니다.
소스로 “GitHub”를 선택하는 이유는 샘플 GitHub 리포지토리가 그곳에 호스팅되어 있기 때문입니다.
4단계
Repository HTTPS URL을 https://github.com/iamvickyav/spring-boot-h2-war-tomcat.git로 입력하고 “검증”을 클릭합니다.
우리의 GitHub 리포지토리가 공개 리포지토리로 호스팅되어 있으므로 액세스하기 위한 자격 증명을 구성할 필요가 없습니다. 기업/개인 리포지토리의 경우 액세스하기 위한 자격 증명이 필요할 수 있습니다.
“자격 증명 확인” 메시지는 Jenkins 서버와 Git 리포지토리 간의 연결이 성공적인 것을 나타냅니다.
5단계
나머지 구성 섹션들은 일단 그대로 두고 맨 아래에 있는 “저장” 버튼을 클릭합니다.
저장하면 Jenkins가 자동으로 다음 단계를 수행합니다:
리포지토리 스캔 단계
- 구성한 Git 리포지토리를 스캔합니다.
- Git 리포지토리에서 사용 가능한 브랜치 목록을 찾습니다.
- Jenkinsfile이 있는 브랜치를 선택합니다.
빌드 실행 단계
- 각 브랜치에 대해 이전 단계에서 찾은 브랜치를 Jenkinsfile에 언급된 단계로 빌드를 실행합니다.
“레포지토리 스캔 로그” 섹션에서 레포지토리 스캔 단계 중에 무슨 일이 일어났는지 이해할 수 있습니다.
우리의 git 레포에는 마스터 브랜치만 있기 때문에 레포지토리 스캔 로그에는 “처리된 브랜치가 1개”라고 나와 있습니다.
스캔이 완료되면 Jenkins는 각 처리된 브랜치에 대해 빌드 작업을 생성하고 실행합니다.
이 경우, 마스터라는 하나의 브랜치만 있었으므로 빌드는 마스터 브랜치에 대해서만 실행됩니다. 왼쪽 메뉴의 “상태”를 클릭하여 확인할 수 있습니다.
상태 섹션에서 마스터 브랜치에 대한 빌드 작업이 생성된 것을 볼 수 있습니다.
브랜치 이름을 클릭하여 빌드 작업 로그 및 상태를 확인할 수 있습니다.
“스테이지 뷰”는 각 스테이지가 실행되는 데 걸린 시간과 빌드 작업의 상태를 시각적으로 표현합니다.
빌드 작업 실행 로그 액세스
1단계
“빌드 번호”를 “빌드 기록” 섹션에서 클릭합니다.
2단계
다음으로 왼쪽 메뉴에서 “콘솔 출력”을 선택하여 로그를 볼 수 있습니다.
git 레포에 브랜치가 하나 이상인 경우 어떻게 될까요? 이제 확인해 봅시다.
git 레포에 “개발”이라는 새 브랜치가 생성되었습니다.
“개발” 브랜치 빌드를 구분하기 위해 Jenkinsfile의 echo 명령어를 약간 수정했습니다.
마스터 브랜치의 Jenkinsfile
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code"
"""
}
}
}
}개발 브랜치의 Jenkinsfile
pipeline {
agent any
stages {
stage('Build Code') {
steps {
sh """
echo "Building Artifact from Develop Branch"
"""
}
}
stage('Deploy Code') {
steps {
sh """
echo "Deploying Code from Develop Branch"
"""
}
}
}
}이제 두 가지 다른 브랜치에 대해 두 개의 Jenkinsfile이 있습니다. Jenkins에서 저장소 스캔을 다시 실행하여 동작을 확인해 봅시다.
새로운 브랜치(개발 브랜치)가 Jenkins에서 감지되었습니다. 따라서 개발 브랜치를 위한 새 작업이 별도로 생성되었습니다.
“develop”을 클릭하면 개발 브랜치 빌드 작업 로그를 볼 수 있습니다.
이전 예제에서는 마스터 브랜치와 개발 브랜치의 Jenkinsfile에 서로 다른 내용을 유지했습니다. 그러나 실제 응용 프로그램에서는 이렇게 하지 않습니다. 브랜치를 확인하기 위해 stage 블록 내에서 when 블록을 활용합니다.
여기에 마스터와 개발 브랜치를 위한 결합된 단계가 포함된 예제가 있습니다. 이 내용은 마스터 및 개발 브랜치의 Jenkinsfile에 모두 배치됩니다.
pipeline {
agent any
stages {
stage('Master Branch Deploy Code') {
when {
branch 'master'
}
steps {
sh """
echo "Building Artifact from Master branch"
"""
sh """
echo "Deploying Code from Master branch"
"""
}
}
stage('Develop Branch Deploy Code') {
when {
branch 'develop'
}
steps {
sh """
echo "Building Artifact from Develop branch"
"""
sh """
echo "Deploying Code from Develop branch"
"""
}
}
}
}단계 3
Jenkins의 왼쪽 메뉴에서 “저장소 스캔”을 클릭하여 Git 저장소에서 새 변경 사항을 감지하도록 합니다.
이 시점에 주목했을 수도 있지만, Jenkins가 변경 사항을 감지하기 위해 매번 저장소를 스캔하고 있습니다.
이 단계를 자동화하는 방법은 어떨까요?
Jenkins 다중 브랜치 파이프라인 스캔을 위한 주기적 트리거
단계 1
왼쪽 메뉴에서 “구성”을 클릭합니다.
단계 2
아래로 스크롤하여 “레포지토리 트리거 스캔” 섹션으로 이동하여 “다른 방식으로 실행되지 않는 경우 주기적으로” 체크박스를 활성화하고 스캔이 주기적으로 실행되는 시간 간격을 선택하세요(이 예시에서는 2분 간격임).
3단계
“저장” 버튼을 클릭하세요.
이제부터 Jenkins는 매 2분마다 레포지토리를 스캔합니다. 어떤 브랜치에서든 새로운 커밋이 발견되면 Jenkins는 해당 브랜치에 대한 새로운 빌드 작업을 Jenkinsfile을 사용하여 실행합니다.
아래는 “레포지토리 스캔 로그”로, 매 2분마다 스캔이 트리거되는 것을 명확히 보여줍니다.
Jenkins 멀티브랜치 파이프라인의 실시간 사용 사례
다음은 Jenkins 멀티브랜치 파이프라인이 유용할 수 있는 몇 가지 시나리오입니다:
- 마스터 브랜치에 새로운 커밋이 있으면 서버에 자동으로 배포되어야 합니다.
- 개발자가 브랜치를 개발하기 위해 풀 리퀘스트(PR)를 생성하려고 하는 경우:
- 코드는 컴파일 오류 없이 성공적으로 빌드되어야 합니다.
- 코드는 최소 80%의 테스트 커버리지를 가져야 합니다.
- 코드는 SONAR 코드 품질 테스트를 통과해야 합니다.
- 개발자들이 마스터나 개발 이외의 브랜치에 코드를 푸시하려고 하는 경우, 코드는 성공적으로 컴파일되어야 합니다. 그렇지 않으면 경고 이메일을 보냅니다.
다음은 위의 몇 가지 사용 사례를 다루는 샘플 Jenkinsfile입니다:
pipeline {
agent any
tools {
maven 'MAVEN_PATH'
jdk 'jdk8'
}
stages {
stage("Tools initialization") {
steps {
sh "mvn --version"
sh "java -version"
}
}
stage("Checkout Code") {
steps {
checkout scm
}
}
stage("Check Code Health") {
when {
not {
anyOf {
branch 'master';
branch 'develop'
}
}
}
steps {
sh "mvn clean compile"
}
}
stage("Run Test cases") {
when {
branch 'develop';
}
steps {
sh "mvn clean test"
}
}
stage("Check Code coverage") {
when {
branch 'develop'
}
steps {
jacoco(
execPattern: '**/target/**.exec',
classPattern: '**/target/classes',
sourcePattern: '**/src',
inclusionPattern: 'com/iamvickyav/**',
changeBuildStatus: true,
minimumInstructionCoverage: '30',
maximumInstructionCoverage: '80')
}
}
stage("Build and Deploy Code") {
when {
branch 'master'
}
steps {
sh "mvn tomcat7:deploy"
}
}
}
}이 새로운 Jenkinsfile을 master 및 develop 브랜치에 커밋했으므로, 다음 저장소 스캔에서 Jenkins 멀티브랜치가 감지할 수 있습니다.
Jenkins 멀티브랜치 파이프라인으로 Selenium 자동화 테스트
웹사이트에 대한 자동화 테스트 사례를 작성하고 있다고 가정합시다. 새 테스트 사례가 브랜치에 커밋될 때마다 이들을 실행하고 예상대로 실행되고 있는지 확인하고 싶습니다.
모든 브랜치에 대한 자동화 테스트 사례를 실행하는 것은 모든 개발자에게 악몽이 될 수 있습니다. 그것이 바로 LambdaTest의 강력한 자동화 테스트 인프라가 유용할 수 있는 곳입니다.
LambdaTest Selenium 그리드를 사용하여 브랜치 커버리지를 극대화할 수 있습니다.
이 섹션에서는 Jenkins 멀티브랜치 파이프라인과 함께 LambdaTest의 테스트 인프라를 활용하는 방법을 살펴보겠습니다. 설명을 위해 여기 LambdaTest ToDo App에 샘플 Todo 앱을 호스팅했습니다. Cucumber로 작성된 자동화 테스트 사례가 샘플 저장소에 커밋되었습니다.
Jenkins에서 이러한 테스트 사례를 LambdaTest 플랫폼에서 실행하려고 합니다. LambdaTest에서 테스트 사례를 실행하려면 사용자 이름과 accessToken이 필요합니다. LambdaTest 플랫폼에 무료로 등록하여 자격 증명을 받으십시오.
환경 변수 설정
테스트 사례가 실행될 때 LambdaTest 사용자 이름(LT_USERNAME)과 암호(LT_ACCESS_KEY)를 환경 변수에서 찾습니다. 따라서 미리 구성해야 합니다.
소스 코드에 저장하지 않도록 Jenkins에서 비밀로 구성하고 환경 변수를 로드했습니다:
environment {
LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
LT_USERNAME = "$LAMBDATEST_CRED_USR"
LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
}다음은 최종 Jenkinsfile입니다:
pipeline {
agent any
tools {
maven 'MAVEN_PATH'
jdk 'jdk8'
}
stages {
stage("Tools initialization") {
steps {
sh "mvn --version"
sh "java -version"
}
}
stage("Checkout Code") {
steps {
checkout scm
}
}
stage("Check Code Health") {
when {
not {
anyOf {
branch 'master';
branch 'develop'
}
}
}
steps {
sh "mvn clean compile"
}
}
stage("Run Test cases in LambdaTest") {
when {
branch 'develop';
}
environment {
LAMBDATEST_CRED = credentials('Lambda-Test-Credentials-For-multibranch')
LT_USERNAME = "$LAMBDATEST_CRED_USR"
LT_ACCESS_KEY = "$LAMBDATEST_CRED_PSW"
}
steps {
sh "mvn test"
}
}
}
}이제 위의 섹션에서 언급한 단계를 따라 Jenkins에서 다중 브랜치 파이프라인으로 “작업”을 새로 생성해 보겠습니다. 샘플 저장소를 가리키도록 하겠습니다.
빌드가 성공적으로 실행되면 LambdaTest 자동화 대시보드를 방문하여 테스트 로그를 확인하세요.
결론
이를 통해 Jenkins 다중 브랜치 파이프라인을 생성하는 방법, 그 안에서 git 저장소를 구성하는 방법, 서로 다른 브랜치에 대한 다양한 빌드 단계, Jenkins에 의한 저장소의 주기적인 자동 스캔 사용 및 LambdaTest의 강력한 자동화 테스트 인프라를 활용하여 CI/CD 빌드를 자동화하는 방법에 대해 배웠습니다. 이 글이 유용하셨다면 좋겠습니다. 의견 섹션에서 피드백을 공유해 주세요.
Source:
https://dzone.com/articles/how-to-create-jenkins-multibranch-pipeline