본문 바로가기

분류 전체보기

(136)
[Jenkins] 실무 최악의 Jenkins 장애 대처 Best 3 길고 길었던 [Jenkins 실무 완벽 가이드] 40부작 대장정의 마지막 장에 오신 것을 환영합니다! 그동안 우리는 도커(Docker) 띄우기부터 파이프라인 문법, 보안, 분산 아키텍처까지 젠킨스의 모든 찬란한 기능들을 완벽히 마스터했습니다. 여러분은 이제 회사에서 "CI/CD 마스터"라는 칭호를 얻었을 것입니다. 하지만 인프라 엔지니어의 진짜 실력은 평화로울 때가 아니라, 모두가 퇴근한 금요일 밤 11시에 시스템이 완전히 먹통이 되었을 때 어떻게 응급 복구를 해내느냐에서 판가름 납니다. 수년간 수백 대의 젠킨스 서버를 운영하며 필자가 피눈물을 흘리며 겪었던 가장 끔찍하고 빈번한 젠킨스 장애 3가지와, 그 장애를 3분 만에 진압하는 '응급 처치(Troubleshooting) 노하우'를 다뤄보겠습니다.💣..
[Jenkins] Master-Slave 분산 빌드: 단일 서버의 한계를 돌파하라 처음 젠킨스를 도입했을 때, 우리는 AWS EC2 t3.medium 서버 한 대에 젠킨스를 설치하고 모든 것을 거기서 해결했습니다. 소스코드를 다운받고, 무거운 자바(Java) 컴파일을 돌리고, 도커 이미지를 구워서 압축하고 푸시하는 이 모든 '막노동'을 젠킨스 서버 혼자서 처리했죠. 파이프라인이 5~10개일 때는 괜찮았습니다. 하지만 회사가 폭풍 성장하여 개발자가 100명이 넘어가고, 출근 직후인 오전 10시에 50개의 빌드가 동시에 트리거(Trigger)되는 순간 재앙이 시작됩니다. CPU 사용률 100%, 메모리(RAM) 풀, 디스크 I/O 병목으로 인해 젠킨스 웹 브라우저 UI 자체가 접속 불가 상태로 하얗게 뻗어버립니다. 서버 한 대로는 더 이상 버틸 수 없는 물리적 한계점(Bottleneck)..
[Jenkins] 공유 라이브러리 심화: 글로벌 vs 폴더 라이브러리 완벽 분리 전략 20단계에서 우리는 slackNotify(), buildDocker()와 같은 공통 함수들을 뽑아내어 재사용하는 '공유 라이브러리(Shared Library)'의 마법을 맛보았습니다. 이 신세계를 접한 여러분의 회사는 젠킨스 [관리 설정] 메뉴에 'Global Pipeline Libraries'를 떡하니 등록하고, 모든 부서(결제팀, 회원팀, 정산팀)가 이 공용 라이브러리 하나를 끌어다 쓰기 시작했습니다. 그런데 어느 날, 회원팀의 신입 데브옵스 엔지니어가 도커 빌드 함수 로직을 살짝 수정하고 커밋(Commit)했습니다. 그 순간, 회원팀뿐만 아니라 결제팀, 정산팀 등 회사 내의 모든 200개 파이프라인이 동시에 줄줄이 빨간불을 뿜으며 빌드 실패로 폭발해버렸습니다! 글로벌(전역) 변수의 무서움을 뼈저리게..
[Jenkins] Upstream/Downstream: 거대 파이프라인 쪼개기 아키텍처 지금까지 우리는 하나의 거대한 Jenkinsfile 안에 빌드, 테스트, 소나큐브 검사, 도커 이미지 푸시, K8s 배포까지 모든 로직을 때려 넣는 단일 파이프라인(Monolithic Pipeline) 방식을 배웠습니다. 프로젝트 규모가 작을 때는 이것이 편합니다. 하지만 회사가 성장하여 수십 개의 마이크로서비스(MSA)가 얽히고, "A 서비스와 B 서비스가 모두 성공적으로 빌드된 후에야 C라는 통합 결제 서버를 빌드하고 배포하라"는 극악의 워크플로우(Workflow) 요구사항이 떨어지면 어떻게 될까요? 이 모든 것을 파일 하나에 욱여넣으면 코드는 2천 줄이 넘어가고, 중간에 작은 에러 하나만 터져도 2천 줄짜리 거대 공장이 통째로 멈춰버리는 끔찍한 사태가 발생합니다.이번 [Jenkins 실무 완벽 가이..
[Jenkins] Artifact(아티팩트) 보관: 롤백을 위한 최후의 구명조끼 파이프라인이 성공적으로 동작하여 수백 메가바이트짜리 .jar 파일이나 프론트엔드 build.zip 파일이 완성되었습니다. 이 결과물을 운영 서버에 쏘아 보내 배포(Deploy)까지 무사히 마쳤습니다. "아싸, 퇴근이다!" 하고 젠킨스를 닫는 순간, 청천벽력 같은 전화가 걸려옵니다."방금 배포한 버전에 치명적인 결제 버그가 있습니다! 당장 1시간 전에 배포했던 어제 버전 파일로 롤백(Rollback)해 주세요!!"만약 여러분이 파이프라인 최하단에 cleanWs()로 워크스페이스를 싹 비워버렸고, 어제 빌드된 .jar 파일을 그 어디에도 백업해두지 않았다면 어떻게 될까요? 옛날 소스코드를 다시 Git에서 Checkout 받아 10분 동안 땀을 뻘뻘 흘리며 재빌드해야 합니다. 그 10분 동안 회사는 수백만 원..
[Jenkins] Node.js 다중 버전 환경 완벽 통제 가이드 엔터프라이즈 환경에서 젠킨스(Jenkins) 서버 단 1대로 수십 개의 파이프라인을 운영하다 보면 필연적으로 '버전 충돌(Version Conflict)'이라는 거대한 장벽에 부딪히게 됩니다. 가장 대표적인 생태계가 바로 프론트엔드의 Node.js 입니다. 5년 전에 만들어진 구형 레거시 어드민 프로젝트는 반드시 Node.js v14 환경에서만 빌드되며, 오늘 새로 런칭한 최신 React 프로젝트는 Node.js v20 환경을 요구합니다. 만약 젠킨스 호스트 서버 리눅스에 apt-get install nodejs로 14 버전을 깔아버리면 새 프로젝트가 빌드 에러를 뿜고, 20 버전으로 올려버리면 레거시 프로젝트가 죽어버립니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 엔지니어를 골머리 ..
[Jenkins] GitHub PR(Pull Request) 빌드 자동화 구축하기 현대의 소프트웨어 개발은 더 이상 혼자서 코드를 짜고 메인(main) 브랜치에 직접 푸시(Push)하는 방식으로 이루어지지 않습니다. 아무리 실력이 뛰어난 개발자라도 실수를 할 수 있기 때문에, 반드시 PR(Pull Request)을 올려서 동료들에게 코드 리뷰(Code Review)를 받고 안전하게 병합(Merge)하는 절차를 거칩니다. 그런데 리뷰어가 코드를 눈으로만 보고 "음, 버그는 없어 보이네요. LGTM(Looks Good To Me)!"이라고 승인했는데, 막상 머지하고 보니 컴파일 에러가 나거나 유닛 테스트가 박살 나는 경우가 비일비재합니다. 이를 방지하기 위해 "누군가 PR을 올리면 젠킨스가 미리 그 코드를 가져와서 몰래 빌드해 보고, 통과했을 때만 Github에 초록색 V(체크) 표시를 ..
[Jenkins] DevSecOps의 완성: Trivy로 컨테이너 보안 취약점 원천 차단하기 우리는 22단계에서 코드를 도커 이미지(Docker Image)로 굽는 화려한 기술을 배웠습니다. FROM node:14-alpine 같은 베이스 이미지를 가져와서 무심코 컨테이너를 말아 올렸죠. 그런데 만약 그 베이스 이미지 안에 해커가 악용할 수 있는 치명적인 OpenSSL 해킹 취약점(예: Heartbleed)이나 탈취 가능한 루트 권한 버그가 심어져 있다면 어떨까요? 젠킨스가 아무리 배포를 잘해도, 결과적으로는 '보안 폭탄'을 운영 서버 한가운데에 아주 빠르고 정확하게 배달해 주는 꼴이 됩니다. 바야흐로 배포 파이프라인 내부에 보안(Security)을 욱여넣어 강제화하는 DevSecOps(개발-보안-운영)의 시대입니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 전 세계에서 가장 사랑받..
[Jenkins] Discard Old Builds: 디스크 용량 폭발을 막는 자동 청소부 CI/CD 자동화를 성공적으로 안착시키고 나면 하루에도 수십, 수백 번의 빌드가 젠킨스 서버에서 수행됩니다. 팀원들은 클릭 한 번으로 배포되는 쾌감에 취해 끊임없이 파이프라인을 돌려댑니다. 그렇게 6개월 평화로운 시간이 흐른 어느 날, 젠킨스 웹 접속이 갑자기 튕기며 HTTP ERROR 500을 뿜어냅니다. 다급하게 서버 터미널에 접속해 df -h 명령어로 용량을 조회해 보는 순간 눈을 의심하게 됩니다. "사용량(Use%) 100% - No space left on device". 젠킨스의 /var/jenkins_home/jobs 디렉토리 아래에 지난 6개월간 쌓인 수만 개의 텍스트 빌드 로그와 거대한 .jar 아티팩트 파일들이 테라바이트(TB) 단위로 하드디스크를 가득 채워 서버가 질식사해 버린 것입니..
[Jenkins] Retry 블록: 네트워크 장애를 이겨내는 불굴의 오뚝이 파이프라인 CI/CD 자동화를 구축해 놓으면 퇴근 후에도 마음이 편할 줄 알았습니다. 하지만 밤 11시에 슬랙으로 [빌드 실패] 빨간 알람이 울려 부랴부랴 랩탑을 열어보면, 내 코드의 버그가 원인이 아닙니다. "Github에서 소스코드를 다운로드하다가 DNS를 못 찾음", "NPM Registry 서버가 잠시 응답하지 않음", "Docker Hub Rate Limit(속도 제한)에 걸려 이미지 pull 실패" 등 인프라 엔지니어가 통제할 수 없는 '외부 요인(네트워크 지연 및 타임아웃)' 때문에 파이프라인이 터지는 억울한 경우가 실무 빌드 실패의 절반 이상을 차지합니다. 억울하게 실패한 빌드를 데브옵스 담당자가 젠킨스 화면에 접속해 수동으로 'Rebuild' 버튼을 눌러주면 언제 그랬냐는 듯 쌩쌩하게 잘 돌아갑니다..
[Jenkins] Timestamps: 눈먼 로그에 생명력을 불어넣는 시간의 마법 파이프라인이 실패하여 원인을 찾기 위해 젠킨스의 Console Output(콘솔 출력) 화면을 열었습니다. 까만 바탕에 흰 글씨로 찍힌 10만 줄의 로그를 스크롤 하다가 Error: Connection timeout 이라는 문구를 발견했습니다. 그런데 이 에러가 도대체 몇 시 몇 분에 발생한 것인지, 그리고 이 앞의 npm install 스텝에서 도대체 몇 분 동안이나 시간을 끌다가 에러가 난 것인지 알 턱이 없습니다. 기본 젠킨스 로그는 그저 명령어의 결과 텍스트만 차가운 콘솔에 주르륵 뱉어낼 뿐, 어떠한 시간 정보(Time Context)도 제공하지 않기 때문입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 엔지니어의 디버깅 시간을 10배 단축시키고, 파이프라인의 병목(Bottlen..
[Jenkins] Timeout의 미학: 좀비 파이프라인(무한 루프) 방어전 "어? 어제 퇴근할 때 걸어놓은 배포가 오늘 아침까지 안 끝나고 계속 돌아가고 있네?" CI/CD 인프라를 운영하다 보면 누구나 한 번쯤 마주치게 되는 소름 돋는 상황입니다. 쉘 스크립트 안에 잘못 작성된 while(true) 무한 루프 버그, 혹은 외부 API 서버가 죽어서 응답을 주지 않아 무한 대기(Hang)에 빠지는 경우 등 원인은 다양합니다. 문제는 이렇게 '에러를 뿜으며 실패(Failure)하지도 않고, 그렇다고 성공(Success)하지도 않은 채 영원히 멈춰있는 좀비(Zombie) 빌드'들이 젠킨스의 가장 큰 적이라는 점입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 소중한 젠킨스의 워커(Worker) 자원을 갉아먹는 이 좀비 빌드들을 가차 없이 사살해버리는 'Timeout(타임..
[Jenkins] Jenkins 무중단 마이그레이션(Migration) 완벽 가이드 잘 굴러가던 젠킨스 서버를 3년쯤 운영하다 보면 반드시 거대한 장벽과 마주치게 됩니다. "서버 OS 버전이 너무 낮아서 더 이상 보안 패치를 받을 수 없다", "회사 방침으로 AWS에서 GCP로 클라우드를 통째로 이전해야 한다" 같은 거부할 수 없는 인프라 개편 지시가 떨어집니다. 이때 데브옵스 엔지니어의 머릿속은 하얗게 변합니다. 수백 개의 파이프라인 Job들, 정성껏 튜닝해 놓은 플러그인 설정들, 수많은 개발자들의 계정 정보와 보안 키(Credentials)를 새로운 서버에 똑같이 세팅하려면 몇 날 며칠을 밤새워야 할까요? 놀랍게도 정답은 "명령어 몇 줄이면 단 10분 만에 끝난다"입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 엔지니어의 영원한 숙제인 구형 젠킨스 서버에서 신규 ..
[Jenkins] Maven / Gradle 빌드 캐시 최적화 (빌드 시간 10배 단축의 비밀) "코드는 고작 한 줄 수정했는데, 젠킨스 빌드 시간은 무려 15분이나 걸린다?" 자바(Java/Spring Boot) 프로젝트나 Node.js 프로젝트의 파이프라인을 운영하다 보면 가장 많이 듣게 되는 불만 중 하나입니다. 코드를 컴파일하고 테스트하는 데 걸리는 시간은 1분도 안 되지만, 스프링 프레임워크와 수많은 서드파티 라이브러리(.jar 파일들)를 Maven Central이나 원격 저장소에서 다운로드하는 데 14분이 걸리기 때문입니다. 특히 앞서 우리가 칭송했던 'Docker Agent(1회용 멸균 빌드 환경)'를 사용할 경우, 이 문제는 최악의 형태로 발현됩니다. 컨테이너가 뜰 때마다 백지상태이므로 매 빌드마다 수백 메가바이트의 라이브러리를 인터넷에서 새로 받아와야 하니까요.이번 [Jenkins ..
[Jenkins] 주기적 빌드(Cron Trigger) 완벽 가이드: 휴먼 리소스 제로화 우리가 지금까지 구축한 파이프라인은 대부분 누군가 Github에 코드를 푸시(Push)하거나, 젠킨스 화면에서 수동으로 Build Now 버튼을 눌렀을 때(Event-Driven) 동작하는 방식이었습니다. 하지만 실무에서는 사람의 개입이나 특별한 이벤트 없이도 정해진 시간(스케줄)에 스스로 깨어나 묵묵히 돌아가야 하는 백그라운드 작업들이 매우 많습니다. 매일 밤 자정에 도는 무거운 대규모 E2E 통합 테스트, 매일 새벽 3시에 수행되는 데이터베이스 덤프 백업, 매주 월요일 아침 8시에 슬랙으로 전송되는 주간 빌드 통계 리포트 등이 대표적입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 엔지니어가 잠든 시간에도 기계가 스스로 일하게 만드는 Jenkins 스케줄러(Cron Trigger)의..
[Jenkins] Jenkins 백업 스크립트의 정석 (서버가 불타도 3분 만에 부활하기) 데브옵스(DevOps) 엔지니어의 가장 큰 덕목은 배포 속도를 빠르게 만드는 것도 중요하지만, '최악의 장애 상황에서도 인프라를 신속하게 복구(Disaster Recovery)해 내는 것'입니다. 수십 개의 프로젝트 파이프라인과 플러그인, 계정 정보, 복잡한 인증키(Credentials)들이 세팅된 젠킨스 서버의 하드디스크가 어느 날 갑자기 물리적 장애로 뻗어버린다면 어떻게 될까요? 백업이 없다면 전사의 배포 프로세스는 수일 동안 올스톱되며 당신은 시말서를 피할 수 없을 것입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 이러한 끔찍한 재앙을 코웃음 치며 3분 만에 어제 상태로 복구해 내기 위한 완벽하고 효율적인 Jenkins 데이터 백업 스크립트 작성 노하우와 AWS S3 이중화 전략에 대하..
[Jenkins] Input Step: 상용 배포 전 수동 승인(결재) 결계 치기 "CI/CD 자동화가 너무 완벽하게 구축된 나머지, 누군가 실수로 main 브랜치에 올린 불량 코드가 5분 만에 전 세계 고객이 접속 중인 운영 서버(Production)에 꽂혀버렸다." 이는 구글, 아마존 같은 빅테크에서도 종종 벌어지는 악몽 같은 장애 시나리오입니다. 개발(Dev) 서버나 스테이징(Staging) 환경까지는 코드가 푸시되는 즉시 100% 논스톱 자동 배포가 이루어지는 것이 맞습니다. 하지만 회사의 명운이 달린 운영 상용 배포 앞에는 반드시 '책임자의 눈과 버튼 승인'이라는 휴먼 브레이크 장치가 필요합니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 질주하는 파이프라인을 잠시 일시 정지(Pause)시키고, 권한을 가진 자만이 문을 열어줄 수 있게 만드는 강력한 'Input St..
[Jenkins] Kubernetes(K8s) 완벽 연동: 무중단 배포 자동화의 끝판왕 앞선 22단계를 통해 애플리케이션 코드를 아름다운 도커 이미지(Docker Image)로 굽고 레지스트리에 푸시(Push)하는 것까지 성공하셨습니다. 이제 남은 과제는 단 하나, "이 이미지를 실서비스가 돌아가고 있는 운영 서버들에 띄워서 고객들에게 선보이는 것"입니다. 현대의 대규모 인프라에서는 이 서버들을 지휘하기 위해 Kubernetes(쿠버네티스, 이하 K8s)라는 막강한 오케스트레이션 툴을 사용합니다. 젠킨스가 빌드마스터라면, K8s는 함대 사령관입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 젠킨스가 원격 K8s 클러스터에 접속하여 새로운 버전의 이미지를 무중단(Rolling Update)으로 교체하라고 명령을 내리는 완벽한 배포 연동 전략에 대하여 다뤄보겠습니다.🔐 1. Kub..
[Jenkins] Jenkins와 Docker 통합 가이드: Build & Push 자동화 과거에는 젠킨스가 빌드한 결과물(예: .jar, .war, 빌드된 React 정적 파일)을 운영 서버에 scp나 rsync로 전송하여 덮어씌우는 방식이 주류였습니다. 하지만 바야흐로 컨테이너(Container)의 시대가 도래했습니다. 이제는 빌드 산출물을 압축해서 보내는 것이 아니라, OS와 런타임 환경까지 통째로 얼려버린 도커 이미지(Docker Image)를 만들어 굽고(Build), 원격 이미지 저장소(Registry)로 밀어 넣는(Push) 작업이 현대 CI/CD의 알파이자 오메가가 되었습니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 불변성(Immutable Infrastructure)을 실현하는 Jenkins Pipeline 내에서의 우아한 Docker 제어 기법과 플러그인 ..
[Jenkins] SonarQube 연동: 불량 코드 자동 차단 시스템 (Quality Gate) 아무리 빠르고 완벽한 CI/CD 배포 파이프라인을 구축했다 한들, 개발자가 푸시한 코드 내부에 심각한 보안 취약점이나 NullPointerException을 유발할 버그가 숨어있다면 무슨 소용일까요? 버그가 듬뿍 담긴 코드를 운영 서버에 가장 빠르고 정확하게 꽂아 넣는 '자동화된 재앙 생성기'로 전락할 뿐입니다. 진정한 데브옵스(DevOps)는 단순히 배포만 해주는 것이 아니라, 품질 기준에 미달하는 쓰레기 코드(Bad Code)가 감지되면 그 즉시 파이프라인의 목을 비틀어 빌드를 강제 중단(Abort)시키는 무자비한 문지기 역할을 해야 합니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 전 세계 정적 코드 분석 시장의 절대 강자인 SonarQube(소나큐브)를 젠킨스와 연동하여, 완벽한 'Qu..
[Jenkins] Shared Library: 전사 파이프라인 중복 제거의 마법 우리는 지금까지 하나의 프로젝트를 위한 완벽한 Jenkinsfile을 작성하는 법을 배웠습니다. 환경변수를 세팅하고, Slack 알림을 붙이고, 병렬 빌드까지 최적화했습니다. 그런데 만약 회사가 성장하여 마이크로서비스 아키텍처(MSA)를 도입하게 되고, 관리해야 할 서버가 50개로 늘어난다면 어떻게 될까요? 50개의 프로젝트 레포지토리에 똑같이 생긴 수백 줄짜리 Jenkinsfile을 복사해서 붙여넣기(Copy & Paste) 하실 건가요? 만약 보안팀에서 "내일부터 배포 알림 메시지 포맷을 변경하세요"라고 지시한다면, 50개의 레포지토리를 돌며 일일이 코드를 수정하고 50번의 커밋을 해야 하는 유지보수 지옥이 열립니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 관리자를 이 끔찍한 복붙..
[Jenkins] 병렬(Parallel) 빌드로 파이프라인 속도 혁신하기 파이프라인을 성공적으로 구축하고 자동화의 기쁨을 누리는 것도 잠시, 프로젝트의 덩치가 커지면서 빌드 시간이 점점 늘어나기 시작합니다. 프론트엔드 빌드 5분, 백엔드 스프링 빌드 5분, 유닛 테스트 5분, E2E 테스트 10분... 코드를 하나 푸시하고 나서 무려 25분을 기다려야 배포가 완료된다면 개발팀의 생산성은 바닥을 칠 것입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 "시간이 돈"인 현대 소프트웨어 개발 환경에서 가장 적은 노력으로 빌드 시간을 드라마틱하게 반토막 내버리는 '병렬(Parallel) 처리 기법'에 대하여 다뤄보겠습니다.⏳ 1. 직렬 빌드의 치명적인 병목 현상기본적으로 젠킨스의 stages 블록 안에 적힌 stage들은 위에서 아래로 순차적(직렬)으로 실행됩니다. 앞의 작..
[Jenkins] Blue Ocean의 마법: 젠킨스 UI/UX의 위대한 혁신 강력하고 견고한 CI/CD 파이프라인 로직을 완벽하게 짰다 하더라도, 그것을 사용하는 주체는 결국 '사람(개발자)'입니다. 기존 젠킨스(Jenkins)의 클래식 인터페이스를 처음 접하는 주니어 개발자들은 90년대 감성의 회색 텍스트와 파란색 동그라미(성공), 빨간색 동그라미(실패) 덩어리를 보며 큰 진입 장벽과 거부감을 느낍니다. 특히 빌드가 실패했을 때, 까만 터미널 화면에 찍힌 수만 줄짜리 콘솔 로그(Console Output)를 눈알이 빠지도록 스크롤을 내리며 에러 원인을 찾는 과정은 크나큰 고통입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 이 모든 칙칙한 UI를 현대적이고 세련된 시각적 대시보드로 180도 뒤집어주는 'Blue Ocean(블루 오션) 플러그인'의 혁신적인 기능과 10..
[Jenkins] Multibranch Pipeline: 무한 증식 브랜치 자동화의 끝판왕 우리는 지금까지 단일 파이프라인(Pipeline) Job을 생성하여 빌드하는 법을 배웠습니다. 하지만 현대 소프트웨어 개발은 Git Flow나 Github Flow를 기반으로, 기능(Feature) 하나를 개발할 때마다 새로운 브랜치를 수십 개씩 파고(Branching) 합치는(Merge) 과정을 밥 먹듯이 반복합니다. 만약 새로운 브랜치가 생성될 때마다 젠킨스 관리자가 웹 UI에 접속해서 "새 잡(Job) 만들기 -> 복사하기 -> 브랜치명 수정" 노가다를 하고 있다면, 그것은 파이프라인이 아니라 수동 라인입니다.이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 관리자의 잡(Job) 복제 스트레스를 0으로 만들어버리는 Multibranch Pipeline(다중 브랜치 파이프라인)의 엄청난 자..

티스토리툴바