얼쑤의 Jenkins는 개발 브랜치 변경을 감지하면 백엔드를 검사하고 배포했습니다. 뒤이어 웹 잡도 자동으로 예약되는 구조여서, 백엔드 변경을 운영에 올릴 때도 별도의 웹 빌드가 시작됐습니다. 웹 배포 시점을 따로 정할 수 있게 트리거를 나누되, 운영 웹이 어떤 소스에서 나왔는지는 계속 확인할 수 있어야 했습니다.

수동 배포에서 소스 SHA 지정

백엔드의 자동 배포는 두고, 웹은 트리거가 없는 전용 잡으로 옮겼습니다. 운영자는 성공한 백엔드 빌드에서 검증한 전체 커밋 SHA를 웹 잡에 입력합니다. 웹 잡은 체크아웃 결과가 입력과 같고 해당 SHA가 개발 브랜치 이력에 포함되는지 확인한 뒤 빌드를 시작합니다. 기존 웹 잡은 비활성화해 이력 조회용으로 남겼습니다.

자동 예약과 수동 배포 검증

분리 뒤 실제 백엔드 SCM 실행 한 건이 배포까지 성공했고, 운영 컨테이너의 JAR은 그 커밋과 일치했고 API readiness는 UP이었습니다. 같은 관측에서 웹 예약과 새 실행은 각각 0건이었습니다. 이력용 잡은 이름을 바꾼 경로에서 과거 빌드 두 건을 다시 찾았고, 한 건은 새 경로에서도 확인되지 않았습니다.

첫 수동 실행에는 백엔드가 검증했고 이미 운영에 반영돼 있던 SHA를 지정했습니다. 새 작업공간에서 wasm-opt가 실제로 실행됐고 최적화 단계는 4분 15초였습니다. 브라우저 테스트 1,766건을 통과했고 Jenkins 기록상 웹 배포를 마치기까지 9분 23초가 걸렸습니다. 두 시간은 첫 수동 실행 한 건에서 기록한 값입니다. 운영 HTTPS에서 읽은 릴리스 SHA와 파일 매니페스트 해시가 배포 기록과 일치해, 요청한 소스가 운영까지 이어졌음을 확인했습니다.