소개
Pine & Path는 정원 산책 행사를 준비하고 있습니다. 한 편집자가 시작 시각을 늦춰 달라고 요청하고, 이어서 다른 편집자가 모임 장소를 변경합니다. Jenkins는 어느 공지든 준비하고 게시할 수 있지만, 승인을 기다리던 이전 실행이 방문객에게 이미 공개된 새 공지를 덮어쓸 수 있습니다.
이 실습에서는 실제로 덮어쓰기가 일어나는 것을 확인한 다음, 새 실행이 대기 중인 이전 실행을 자동으로 대체하도록 Pipeline을 변경합니다. 결과물은 최신 요청과 일치하는 경로, 일정, 안내문을 갖춘 실제 방문객 공지와 다운로드할 수 있는 일곱 파일의 패키지입니다.
전제 지식은 기본적인 Jenkins 페이지 탐색과 짧은 Declarative Pipeline을 알아보는 능력입니다. 매개변수, 승인을 위한 일시 정지, 동시 실행 설정은 여기서 설명합니다. Jenkins, 컨트롤러 실행기 두 개, 공지 도구, 로컬 Notice Desk가 준비되어 있습니다. 소프트웨어를 설치하거나 웹사이트를 작성할 필요는 없습니다. 두 인터페이스는 하나의 훈련용 VM에서 실행됩니다. 이는 통제된 로컬 게시 시스템이며 운영용 배포 플랫폼이 아닙니다. 소요 시간은 작성자의 예상치이며, 초보자를 대상으로 측정한 값은 아닙니다.
늦은 승인으로 공지가 덮어써지는 현상 관찰하기
이 단계에서는 최신 공지를 게시한 다음, 대기하던 이전 실행이 이를 덮어쓰는 것을 관찰합니다. Notice Desk에서 시작하세요. 이 인터페이스는 열어 두세요. 인터페이스를 전환해도 빌드가 다시 시작되거나 공지가 초기화되지 않습니다.
정상적인 방문객 이용 과정 살펴보기
첫 번째 행사는 정원 산책입니다. 해당 행사의 View notice 링크를 선택하세요. 제공된 공지에는 Community Gate에서 10:00에 시작한다고 되어 있습니다. Open the route를 열고 경유지 세 곳을 살펴보세요. 브라우저의 Back 동작으로 공지로 돌아가세요. Read visitor notes를 열어 모임 안내를 읽은 다음 Back으로 다시 돌아오세요. Schedule table은 CSV 파일입니다. CSV는 필드를 쉼표로 구분하는 단순한 표입니다. Notice details는 JSON이며, 같은 행사를 설명하는 이름 붙은 값들입니다. Preparation record는 이 패키지를 준비한 방법을 식별합니다. 현재는 실제 상태대로 PROVIDED BASELINE이라고 표시됩니다. 초기 설정이 대신 Jenkins 작업을 실행한 것은 아닙니다.
브라우저의 Back 동작으로 Notice Desk 홈으로 돌아가세요. 정원 산책의 Download notice pack을 선택하고 ZIP 아카이브를 저장하세요. ZIP은 여러 파일을 함께 묶어 둡니다. 컴퓨터의 압축 해제 도구로 아카이브 전체를 새 폴더에 추출한 다음, 그 안의 index.html을 여세요. 주변의 일곱 파일을 모두 함께 유지하세요. 경로, 스타일시트, 일정, 안내문, JSON, 준비 기록은 실제 로컬 파일입니다. index.html만 옮기면 주변 파일 링크가 작동하지 않습니다. 브라우저는 CSV나 텍스트 파일을 바로 열 수도 있고 다운로드할 수도 있습니다. 어느 동작이든 저장된 실제 내용을 읽는 데 적합합니다.
Notice Desk 홈으로 돌아가세요. 별도의 Seed Swap 공지와 다운로드를 살펴보세요. Potting Shed에서 11:00에 시작하며, 변경하지 않아야 합니다. 앞으로 처리할 편집자 요청은 정원 산책에만 해당합니다.
Read the editor requests를 선택하세요. 이전 요청의 UPDATE 값은 later-start이며, 10:30으로 늦추되 장소는 여전히 Community Gate입니다. 최신 요청은 new-meeting-point입니다. 10:30을 유지하고 Glasshouse Gate에서 모입니다. 여기서 ‘최신’은 나중에 들어온 편집자 요청을 뜻하며, 우연히 마지막에 끝난 빌드를 뜻하지 않습니다.
준비된 Pipeline 읽기
Jenkins로 전환하세요. publish-walk-notice를 연 다음 Configure를 선택하세요. Pipeline 섹션과 Script 편집기를 찾으세요. 이는 Declarative Pipeline입니다. 바깥의 pipeline { ... } 블록이 작업을 설명하며, 짝이 맞는 중괄호가 설정과 단계들을 묶습니다.
이 작업은 agent any를 사용하여 사용 가능한 준비된 노드에 실행기와 작업 공간을 할당합니다. 실행기는 작업을 실행하는 Jenkins 슬롯이며, 작업 공간은 실행의 작업 디렉터리입니다. 이 훈련용 컨트롤러에는 실행기가 두 개 있어 이 작업의 두 실행이 겹칠 수 있습니다. 각각 별도의 작업 디렉터리를 사용하지만 같은 정원 공지에 게시합니다.
parameters 블록은 빌드마다 선택할 값을 정의합니다. choice는 두 편집자 요청을 UPDATE로 제공합니다. booleanParam은 HOLD_FOR_REVIEW를 체크박스로 만듭니다. 선택하면 true, 선택하지 않으면 false입니다. params.HOLD_FOR_REVIEW는 해당 실행에서 선택한 값을 읽습니다. when 조건은 표현식이 참일 때만 해당 단계를 실행합니다.
세 단계는 각각 다른 목적을 가집니다.
- Prepare notice는
deleteDir()로 실행의 작업 공간을 비우고,sh로 제공된 준비 프로그램을 호출한 뒤notice-pack.zip을 보관합니다.archiveArtifacts는 해당 파일 자체를 Jenkins 빌드와 함께 보관합니다.fingerprint: true는 내용 식별 정보와 연결된 빌드를 기록합니다. 준비와 보관은 방문객 공지를 변경하지 않습니다. - Review notice는 검토 체크박스를 선택한 실행을 게시 전에
input으로 일시 정지합니다. Proceed 링크는 다음 단계를 허용하고, Abort는 해당 실행을 취소합니다. 연결 실패가 아니라 의도된 일시 정지입니다. - Publish notice는 준비된 패키지를 로컬 Notice Desk로 전송합니다.
post { always { ... } }블록은 중단된 경우를 포함하여 실행이 끝날 때 작업 공간을 비웁니다. Jenkins에 보관된 파일은 작업 공간 정리 후에도 계속 사용할 수 있습니다.
제공된 준비 및 게시 프로그램은 실제 빌드의 매개변수와 아카이브를 읽습니다. 이 프로그램들, 모든 단계, 검토 조건, 지문 기록, 두 정리 작업을 유지하세요. 다음 단계에서는 겹치는 실행을 처리하는 방식만 변경합니다. 지금은 Script를 그대로 두세요. Save를 선택하여 작업으로 돌아가세요.
이전 실행을 시작하고 대기 상태로 두기
publish-walk-notice 작업 페이지에서 Build with Parameters를 선택하세요. UPDATE에 later-start를 선택하고, 레이블이나 체크박스를 클릭하여 HOLD_FOR_REVIEW를 선택하세요. Build를 한 번 선택하세요.
Build History에서 새로 시작된 실행을 여세요. 아직 사용하지 않은 작업이라면 #1입니다. Console Output을 여세요. Proceed 및 Abort 링크와 함께 **Release this selected notice?**가 나타날 때까지 기다리세요. 그대로 대기하게 두세요. 콘솔은 이미 준비와 보관을 보고했습니다. Publish notice가 실행되지 않았으므로 작업의 공유 방문객 공지는 여전히 초기 상태입니다.
위쪽의 publish-walk-notice 이동 경로 링크로 작업 페이지에 돌아가세요. 이는 Jenkins 내부 탐색이며, Notice Desk 인터페이스로 전환하는 것과 다릅니다. 대기 중인 콘솔로 돌아올 수 있도록 이전 실행 번호를 기록하세요.
Build with Parameters를 다시 선택하세요. 이번에는 new-meeting-point를 선택하고 HOLD_FOR_REVIEW는 선택하지 않은 상태로 두세요. Build를 한 번 선택하세요. 새 실행의 Console Output을 열고 Finished: SUCCESS를 기다리세요. 아직 사용하지 않은 작업에서 순서대로 진행했다면 #2입니다.
Notice Desk로 전환하고 홈을 새로 고침하세요. 정원 공지를 여세요. 이제 10:30과 Glasshouse Gate가 표시되어야 합니다. 경로와 방문객 안내문을 열어 같은 모임 장소를 확인하세요. 최신 편집자 요청이 실제로 게시되었습니다.
이전 실행 계속하기
Jenkins로 돌아가세요. 작업으로 돌아가 기록해 둔 이전 실행과 Console Output을 연 다음, 해당 실행의 Proceed 링크를 선택하세요. Finished: SUCCESS를 기다리세요. 오래된 콘솔 화면을 열어 두었다면 링크를 선택하기 전에 해당 실행의 콘솔을 새로 고침하세요. 페이지를 새로 고치기 위해 다른 빌드를 시작하지 마세요.
Notice Desk로 전환하고 새로 고침한 뒤 정원 공지를 다시 살펴보세요. 이제 Community Gate에서 10:30이라고 표시됩니다. 이것이 예상된 문제입니다. 이전 실행이 더 늦게 끝나 최신 요청을 덮어썼습니다. 두 Jenkins 실행은 모두 성공했지만, 비즈니스 결과는 오래된 상태가 되었습니다.
현재 패키지를 다른 폴더에 다운로드하세요. publication.txt에는 이전 Jenkins 실행이 명시되어 있으며, 경로, 일정, 안내문은 이전 요청과 일치합니다. Jenkins로 돌아가 이전 빌드의 Build Artifacts 링크를 열고 Jenkins 자체 notice-pack.zip을 다운로드하세요. Notice Desk는 다른 공지를 조용히 생성한 것이 아니라, 실제로 준비된 해당 아카이브를 전달했습니다.
예상과 달리 실행이 대기 중이면 선택한 Parameters와 콘솔을 살펴보세요. 입력 프롬프트에서 Abort를 선택하여 실수로 대기시킨 실행을 취소한 다음, 의도한 매개변수로 다시 시작할 수 있습니다. 모든 빌드 이력을 유지하세요. 프롬프트 전에 나타나는 실패 메시지는 예상된 승인 대기와 다릅니다. 실수로 제공된 단계를 편집했다면 콘솔을 읽고 Configure로 돌아가 복원하세요.
자가 점검: 실제로 성공한 두 빌드, 이전 실행에서 수행한 실제 승인, 오래된 방문객 결과물을 모두 보존했습니다. 별도의 Seed Swap 공지와 다운로드도 여전히 작동합니다. 이후의 수정으로도 이 증거를 지우지 않습니다.
새 실행이 대기 중인 이전 실행을 대체하게 하기
이 단계에서는 이전 승인으로 최신 요청이 덮어써지지 않도록 합니다. Jenkins의 publish-walk-notice 작업 페이지에서 시작하세요.
같은 작업의 겹치는 실행 정책 추가하기
Pipeline의 options 블록은 실행 동작을 제어합니다. disableConcurrentBuilds()만 사용하면 현재 실행이 끝날 때까지 새 실행이 대기열에서 기다립니다. 그러면 이전 승인이 계속 흐름을 결정하게 됩니다. 대신 abortPrevious: true를 설정하면 같은 작업의 새 실행이 시작될 때 이전 실행을 중단합니다. true는 따옴표로 감싼 텍스트가 아니라 불리언 값입니다. 콜론은 이 이름 붙은 옵션을 설정에 전달합니다.
Configure를 선택하고 Pipeline → Script를 찾은 다음, agent any 바로 뒤에 다음 줄을 삽입하세요. 위치는 바깥쪽 pipeline 블록 안이며 parameters 앞입니다.
options { disableConcurrentBuilds(abortPrevious: true) }
시작 부분은 이제 다음과 같아야 합니다.
pipeline {
agent any
options { disableConcurrentBuilds(abortPrevious: true) }
parameters {
이 짧은 발췌문은 위치를 보여 줍니다. Script 전체를 이 발췌문으로 바꾸지 마세요. 기존 매개변수, 단계, 보관, 정리를 유지하세요. Save를 선택하세요. 저장은 이후 실행을 바꾸므로, 효과를 입증하려면 새 실행 두 개를 실행해야 합니다.
자동 대체 관찰하기
작업 페이지에서 Build with Parameters를 선택하고 later-start를 선택한 다음, HOLD_FOR_REVIEW를 선택하고 Build를 선택하세요. 새로 시작한 이전 요청 실행의 Console Output을 열고 실제 Proceed / Abort 프롬프트를 기다리세요. 추가 실행 없이 순서대로 진행했다면 #3입니다. 대기 상태로 두세요. 수동으로 중단하거나 진행하지 마세요.
작업의 이동 경로 링크로 돌아가세요. Build with Parameters를 선택하고 new-meeting-point를 선택한 다음, HOLD_FOR_REVIEW는 선택하지 않은 채 Build를 선택하세요. 더 새로운 이 실행의 콘솔을 열고 Finished: SUCCESS를 기다리세요. 추가 실행 없이 순서대로 진행했다면 #4입니다.
대기하던 이전 실행의 콘솔을 열고 새로 고침하세요. 준비된 Jenkins 버전에서 이 실행은 NOT_BUILT이며, **Superseded by #...**에 더 새로운 실행이 명시됩니다. 이전 Publish notice 단계는 건너뛰었고 정리는 여전히 실행되었습니다. 회색 상태만으로는 충분하지 않습니다. 대체된 원인을 읽고 새 빌드 번호와 비교하세요. 이전 입력은 더 이상 승인을 기다리지 않습니다. 과거 콘솔에는 이전의 Proceed/Abort 텍스트가 여전히 표시될 수 있습니다. 대체된 뒤에는 이 오래된 링크들을 사용하지 마세요.
**Superseded by #...**와 건너뛴 게시 단계를 읽은 다음, 최종 NOT_BUILT 결과와 비교하세요.
여기서 NOT_BUILT는 아무 작업도 수행되지 않았다는 뜻이 아닙니다. 이전 실행은 일시 정지 전에 패키지를 준비하고 보관했습니다. 해당 실행의 Build Artifacts를 열고 notice-pack.zip을 여전히 다운로드할 수 있는지 확인하세요. 정책이 막은 것은 오래된 패키지가 나중에 게시되는 일이었습니다. 두 실행의 작업 공간 정리는 보관된 이 파일들을 그대로 남깁니다.
Notice Desk로 전환하고 새로 고침한 다음 정원 공지를 여세요. Glasshouse Gate에서 10:30이라고 표시되어야 합니다. 경로, 안내문, 일정을 읽으세요.
10:30, Glasshouse Gate, 경로의 첫 경유지를 함께 확인하세요. 홈으로 돌아가 Seed Swap이 여전히 Potting Shed에서 11:00에 시작하는지 확인하세요.
실수로 대기시킨 승인 취소 연습하기
Jenkins로 전환하세요. HOLD_FOR_REVIEW를 선택한 상태로 later-start 빌드를 하나 더 시작하세요. 콘솔 입력 프롬프트를 기다린 다음 Abort를 선택하세요. 이는 의도적인 수동 취소이며 ABORTED로 끝납니다. 앞서 관찰한 자동 대체와는 다르며, 그 증거를 대신하지 않습니다. 이 실행은 게시하지 않았으므로 실제 공지는 Glasshouse Gate를 유지합니다.
마지막으로 HOLD_FOR_REVIEW를 선택하지 않은 상태에서 new-meeting-point 빌드를 시작하고 SUCCESS를 기다리세요. 이는 잘못된 요청을 실수로 일시 정지하거나 취소했을 때의 복구 동작입니다. 편집자 요청 페이지를 살펴보고 최신 요청을 선택한 다음, 대기 없이 빌드하세요. 이전 실행들을 유지하세요. 이력을 삭제하면 정책 동작의 증거가 사라집니다.
Script를 저장한 뒤 구문 메시지와 함께 FAILURE가 발생하면 중괄호 짝을 확인하고, options 줄이 pipeline 안에 있으며 stages나 단계의 steps 안에 있지 않은지 확인하세요. Configure에서 수정하고 저장한 다음 의도한 실행 쌍을 다시 시작하세요. VM을 초기화하거나 제공된 도구를 수정하지 마세요. 추가로 실패한 시도는 이력에 남겨 두어도 됩니다.
최종 결과물 보관하고 살펴보기
Notice Desk로 전환하세요. 새로 고침한 다음 정원의 notice pack을 다운로드하세요. 이전 다운로드 파일과 섞지 말고 새 폴더에 저장하세요. ZIP 전체를 추출하고 index.html을 여세요. Glasshouse Gate, 10:30, 그림으로 표시된 경로와 경유지 세 곳을 모두 확인하세요. Read visitor notes, Schedule table, Notice details, Preparation record를 여세요. CSV와 JSON은 페이지와 일치해야 합니다. publication.txt에는 최종적으로 성공한 Jenkins 작업과 빌드가 명시됩니다. 폴더 전체는 Jenkins나 Notice Desk 없이 로컬에서 작동합니다. 로컬 파일 화면 사이에서는 브라우저의 Back 동작을 사용하세요.
Jenkins에서 해당 성공 빌드와 Build Artifacts를 연 다음 notice-pack.zip을 다운로드하세요. 추출된 일곱 파일은 Notice Desk 다운로드와 일치해야 합니다. Jenkins 자체 아카이브는 빌드가 준비한 것을 기록하고, Notice Desk는 실제 게시된 것을 보여 줍니다.
자가 점검: 저장된 정책이 적용되어 있고, 실제로 더 새로운 실행이 입력에서 일시 정지된 이전 실행을 자동으로 대체했으며, 방문객은 최신 요청의 실제 파일을 받습니다. 일시 정지된 실행과 더 새로운 실행의 쌍은 현재 저장된 이 Script로 실행되었어야 합니다. 가장 최근에 완료된 실행 자체도 최신 요청의 게시에 성공한 실행이어야 합니다. 잘못 게시되었거나 게시를 건너뛰었다면 Script를 복원하고 다시 실행하세요. 동작을 다시 바꾸면 새로운 대기 실행과 더 새로운 실행의 쌍으로 입증하세요. 모든 빌드 이력, 이전 아카이브, 준비·검토·게시·정리 동작, 관련 없는 행사는 온전히 유지해야 합니다.
이 설정은 하나의 작업에서 겹치는 실행에 영향을 줍니다. 중단 전에 이미 이루어진 게시를 되돌리거나, 다른 작업들을 조율하거나, 모든 운영 배포를 안전하게 중단할 수 있게 하지는 않습니다. 여기서는 이전 실행이 단 한 번의 게시 단계 전에 일시 정지하므로 경계가 명확합니다.
요약
실제 방문객 결과를 Jenkins 실행 동작과 연결했습니다. 이전 승인이 더 새로운 공지를 덮어쓰는 현상을 재현한 다음, disableConcurrentBuilds(abortPrevious: true)를 사용하여 새 실행이 같은 작업의 대기 중인 이전 실행을 중단하게 했습니다. 준비와 게시, Jenkins 자체 자동 대체와 수동 취소, 보관된 파일과 작업 공간 파일을 구분했습니다.
최종 결과물은 일치하는 오프라인 경로, 일정, 안내문을 갖춘 최신 정원 공지입니다. 보존된 이력은 성공한 빌드를 통해 의도한 업데이트가 실제 방문객에게 도달했음을 보여 줍니다.
