Multibranch Pipeline 랩

Source: Dev.to

위에 제공된 텍스트 외에 번역할 내용이 없습니다. 번역이 필요한 전체 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.

멀티브랜치가 중요한 이유 (DevOps 관점)

일반 Jenkins 작업에서는 보통 하나의 브랜치를 빌드하고, 웹훅은 종종 “어떤 브랜치/작업”에 매핑되기가 쉽지 않습니다.

멀티브랜치 파이프라인은 자동으로:

• GitHub에서 브랜치를 탐색합니다
• 올바른 브랜치를 자동으로 빌드합니다
• 브랜치당 하나의 작업을 (한 곳에) 생성합니다
• PR 워크플로우를 지원합니다 (실제 팀 CI)
• “Build Now” 클릭 단계를 없앱니다

실제 운영 환경에서는 DevOps가 main만이 아니라 브랜치/PR당 CI를 원합니다.

실제 기업에서는 어떤 브랜치를 사용하나요?

가장 일반적인 프로덕션 패턴

패턴 A (가장 간단하고 일반적)

main          → production‑ready
feature/*     → developer work
PR → merge to main

패턴 B (릴리즈 안정성을 포함)

main          → production
develop       → integration / staging
feature/*     → PR to develop
release       → merge to main

초보자는 패턴 A를 사용하세요.

더 많은 브랜치를 생성해야 하나요?

✅ Yes – 최소 하나의 feature 브랜치는 필요합니다. 멀티브랜치는 여러 개의 브랜치를 자동으로 빌드하도록 설계되었기 때문입니다.

You will create:

• main
• feature/hello-ci

그것이면 충분합니다.

PART 1 – GitHub 저장소 만들기 (Jenkinsfile 포함)

Step 1 – 저장소 만들기

GitHub → New repository

• Name: jenkins-multibranch-lab
• Public or private (either works) → 공개 또는 비공개 (둘 다 가능)

Clone it to your machine. → 내 컴퓨터에 복제합니다.

Step 2 – 파일 만들기

저장소 내부:

app.sh

#!/bin/bash
echo "Hello from branch: $(git rev-parse --abbrev-ref HEAD)"
echo "Running on host: $(hostname)"

test.sh

#!/bin/bash
if [ -f app.sh ]; then
  echo "TEST PASSED"
  exit 0
else
  echo "TEST FAILED"
  exit 1
fi

실행 가능하도록 권한을 부여합니다:

chmod +x app.sh test.sh

Step 3 – Jenkinsfile 추가 (브랜치 인식)

저장소 루트에 **Jenkinsfile**을 생성합니다:

pipeline {
    agent any

    options {
        timestamps()
        disableConcurrentBuilds()
    }

    stages {
        stage('Checkout Info') {
            steps {
                sh '''
                  echo "Branch: ${BRANCH_NAME}"
                  echo "Commit: $(git rev-parse --short HEAD)"
                '''
            }
        }

        stage('Build') {
            steps {
                sh './app.sh'
            }
        }

        stage('Test') {
            steps {
                sh './test.sh'
            }
        }
    }

    post {
        success { echo "CI SUCCESS for ${BRANCH_NAME}" }
        failure { echo "CI FAILED for ${BRANCH_NAME}" }
        always  { cleanWs() }
    }
}

커밋하고 main에 푸시합니다:

git add .
git commit -m "Add multibranch CI lab"
git push origin main

PART 2 – Jenkins에서 멀티브랜치 파이프라인 만들기 (UI 단계)

Step 4 – 작업 생성

Jenkins Dashboard → New Item

• Name: multibranch-ci-lab
• Type: Multibranch Pipeline → OK

Step 5 – 저장소 소스 설정

Branch Sources → Add source → GitHub

• Credentials:

  • Public repo – 필요 없음
  • Private repo – 먼저 Jenkins Credentials에 GitHub 토큰을 추가

• Repository HTTPS URL: 저장소 URL을 붙여넣기.

Step 6 – 빌드 구성

• Mode: by Jenkinsfile
• Script Path: Jenkinsfile (기본값)

Step 7 – 브랜치 탐색 (중요)

Behaviors → Discover branches 를 찾아 활성화합니다.
(추후 선택) “Discover pull requests” 를 활성화할 수 있습니다.

초보자에게 안전한 옵션: 브랜치를 일반적으로 빌드합니다.

Step 8 – 저장 및 스캔

Save 를 클릭합니다. Jenkins가 Scan Multibranch Pipeline을 시작하여 Jenkinsfile이 있는 브랜치를 찾아 자동으로 작업을 생성합니다 (예: main 브랜치에 대한 작업).

PART 3 – 웹훅 (자동으로 트리거되도록)

Step 9 – GitHub 웹훅 설정

GitHub repo → Settings → Webhooks → Add webhook

• Payload URL:

  • Jenkins가 로컬에만 있을 경우 – ngrok/공용 URL 사용
  • Jenkins가 인터넷에서 접근 가능할 경우 – 해당 URL 사용

• Content type: application/json

• Events: 푸시 이벤트만 (초보자용) – 나중에 “Pull request”를 추가할 수 있습니다.

이제 GitHub 푸시가 Jenkins 스캔/빌드를 자동으로 트리거합니다.

PART 4 – 기능 브랜치 생성 (실제 프로덕션 워크플로우)

Step 10 – 기능 브랜치 생성

git checkout -b feature/hello-ci

app.sh를 편집하고 메시지를 변경합니다:

echo "Hello from FEATURE branch"

커밋하고 푸시합니다:

git add app.sh
git commit -m "Update app output on feature branch"
git push -u origin feature/hello-ci

이제 일어날 일

1. GitHub가 웹훅을 전송합니다.
2. Jenkins 멀티브랜치가 새 브랜치를 감지합니다.
3. Jenkins가 자동으로 feature/hello-ci에 대한 작업을 생성하고 CI 파이프라인을 실행합니다 – “Build Now”를 클릭할 필요가 없습니다.

PART 5 – main에 병합 (실제 프로덕션이 어떻게 이루어지는지)

Step 11 – PR 열기

GitHub → Pull Requests → New PR

• Base: main
• Compare: feature/hello-ci

실제 팀에서는:

• PR 리뷰가 진행됩니다.
• 병합 전에 CI가 통과해야 합니다 (브랜치 보호).

PR을 병합합니다.

Step 12 – 병합 후 Jenkins가 수행하는 작업

1. 병합이 GitHub 웹훅을 트리거합니다.
2. Jenkins가 main에 대한 파이프라인을 실행합니다.
3. main에 업데이트된 코드가 포함되고 CI 결과가 표시됩니다.

왜 멀티브랜치가 중요한가

각 브랜치는 main에 병합되기 전에 스스로를 증명합니다.

DevOps가 주의해야 할 사항 (일일 작업)

1) Webhook 상태

푸시가 트리거되지 않나요?

• GitHub에서 Webhook 전달 로그 확인
• Jenkins 로그 검토
• URL 확인 (예: ngrok이 만료되었을 수 있음)

2) Branch Discovery 설정

브랜치가 빌드되지 않나요?

• Jenkins가 해당 브랜치를 발견하지 못했을 수 있음
• 브랜치에 Jenkinsfile이 없을 수 있음
• 필터에 의해 제외되었을 수 있음

3) Credentials

프라이빗 레포가 체크아웃에 실패하나요?

• GitHub 토큰이 누락됨
• 토큰 권한이 올바르지 않음

4) Agents

파이프라인에 agent { label 'mac-agent' }가 사용된 경우

• 에이전트가 온라인 상태여야 함
• 에이전트에 해당 라벨이 존재해야 함

5) Build 안정성

• 불안정한 테스트
• 빌드 시간 과다
• 워크스페이스 정리 문제

왜 기업들은 멀티브랜치가 필요한가 (Production Answer)

멀티브랜치는 다음을 강제합니다:

• 모든 브랜치에 대한 CI (main만이 아니라)
• 자동 브랜치‑잡 생성
• 브랜치 간 일관된 빌드
• PR‑기반 워크플로우
• 수동 클릭 감소
• 명확한 추적성: branch → build → commit

면접 대비 답변

“멀티브랜치 파이프라인은 파이프라인‑as‑code를 사용해 각 브랜치/PR을 자동으로 빌드하도록 하며, 실제 GitHub 워크플로와 일치하고 수동 작업 관리를 방지합니다.”