배포 롤백하기

If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…

배포 롤백이 프로덕션을 중단시키면, 아무것도 다시 빌드하지 않고도 이전 빌드를 몇 초 내에 트래픽 앞으로 되돌릴 수 있습니다. 이 가이드는 롤백의 작동 방식, 올바른 배포를 선택하는 방법, Orbit이 자동으로 수행할 수 있는 롤백, 그리고 롤백 후 해야 할 일을 다룹니다.

롤백 작동 방식

Orbit은 성공한 모든 빌드의 패키지된 아티팩트를 보관합니다. 롤백은 설치 또는 빌드 명령을 다시 실행하지 않습니다. 이미 존재하고 이미 제공된 아티팩트를 승격하므로 몇 초 내에 완료되며 빌드가 실패할 수 있는 어떤 이유로도 실패할 수 없습니다.

이것이 바로 롤백을 가장 먼저 사용해야 하는 이유입니다. 롤백은 더 빠르고 사이트가 중단된 상태에서 문제를 해결하려고 시도하는 것보다 훨씬 더 예측 가능합니다.

이전 배포로 롤백

Orbit에서 프로젝트를 엽니다.
Deployments 탭을 엽니다.
정상이었던 마지막 배포를 찾습니다.
해당 행의 Roll back을 클릭하고 확인합니다.

확인 메시지는 정확히 무엇이 일어날지 설명합니다. 이전 빌드에서 즉시 트래픽이 제공되고 현재 배포가 대체됩니다.

롤백 작업이 있는 Deployments 탭

배포의 자체 상세 페이지에서도 롤백할 수 있으며, 버튼에는 짧은 커밋 해시로 Rollback to라고 표시됩니다.

복원된 배포는 CURRENT 배지를 받습니다. 롤백된 배포는 Rolled back 상태로 기록에 남습니다.

롤백은 파괴적이지 않으며 실행 취소가 필요하지 않습니다. 아무것도 삭제되지 않으며, 기록이 다시 쓰이지 않으며, 리포지토리는 손대지 않습니다. 프로덕션 브랜치에 성공적으로 다음 푸시하면 정상적인 방식으로 새로운 라이브 버전이 됩니다.

올바른 배포 식별

Deployments 탭의 각 행은 커밋 메시지와 짧은 해시, 브랜치, 상태, 배포 시간 및 푸시한 사람을 표시합니다. 라이브인 것은 CURRENT 배지를 갖습니다.

보통 문제를 일으킨 배포 바로 이전 배포를 원합니다. 두 가지가 확실하게 해줍니다:

Compare. 의심되는 배포를 열고 Compare를 클릭하여 이전 배포와 비교합니다. 빌드 시간, 아티팩트 크기, 캐시 상태, 프레임워크 및 파일 수준의 아티팩트 차이를 볼 수 있습니다.
Deployment notes. 모든 배포에는 최대 500자의 메모를 추가할 수 있습니다. "결제 버그 핫픽스" 또는 "기능 플래그 X 켜짐"을 추가하는 것은 비용이 없으며 몇 개월 후 기록을 읽기 쉽게 만들어줍니다. 이는 정확히 필요할 때입니다.

아티팩트로의 롤백은 환경 변수, 리다이렉트 규칙 또는 응답 헤더를 롤백하지 않습니다. 이들은 요청 또는 빌드 시점에 읽혀지며 아티팩트에 굽혀지지 않습니다. 인시던트가 코드 변경이 아닌 구성 변경으로 인해 발생한 경우, 코드를 롤백해도 해결되지 않습니다. 배포 상세 페이지는 빌드 시점에 주입된 변수를 현재 구성과 비교하며, 이것이 두 가지를 구분하는 가장 빠른 방법입니다.

자동 롤백

Orbit은 당신이 알아차리기도 전에 이것을 수행할 수 있습니다. 세 가지 설정 모두 Settings에 있습니다.

실패 시 자동 롤백

Runtime에서 Auto-rollback on failure를 켭니다. 프로덕션 배포가 실패하면 마지막 정상 배포가 자동으로 복원되고 방문자에게는 다운타임이 보이지 않습니다. Staging에도 자체 토글이 있습니다.

Health Check

Health check에서 Health check path를 설정합니다. 예를 들어 / 또는 /api/health입니다. 모든 프로덕션 배포 후 Orbit은 해당 경로를 가져옵니다. 15초 내에 2xx 응답을 반환하지 않으면 이전 정상 배포가 복원됩니다.

Smoke Tests

Smoke tests에서 최대 10개의 쉼표로 분리된 경로를 나열합니다. 예를 들어 /,/blog,/api/health입니다. 성공한 각 배포 후 Orbit은 각각에 GET을 보내고 통과 또는 실패를 기록합니다. 하나라도 실패하고 자동 롤백이 활성화되어 있으면 이전 배포가 복원됩니다. 결과는 배포 페이지에 Smoke tests passed 또는 실패 수로 나타나며, 롤백을 유발한 경우 Triggered rollback이라고 표시합니다.

실제로 데이터베이스를 사용하는 경로의 health check는 홈 페이지의 체크보다 훨씬 더 가치 있습니다. 캐시된 홈 페이지를 여전히 제공하는 손상된 배포는 / 체크를 통과하고 실제 체크는 실패합니다.

롤백 대 배포 잠금

롤백할 준비는 되지 않았지만 조사하는 동안 새로운 것이 라이브로 가는 것을 원하지 않으면 대신 배포를 잠급니다:

프로젝트를 엽니다.
Lock deploys를 클릭합니다.
이유를 추가합니다. 예를 들어 "프로덕션 문제 조사 중".

푸시 트리거 배포는 조용히 건너뛰어지고 배너에는 Production deploys are locked가 표시되고 당신의 이유가 나타납니다. 수동 배포는 여전히 작동하며, 이는 의도적입니다. 잠금은 실수로 인한 배포를 중지하지만 배포하는 수정 사항은 중지하지 않습니다. Unlock deploys를 클릭하여 해제합니다.

잠금과 롤백은 함께 잘 작동합니다. 먼저 롤백하여 서비스를 복원한 후 누군가의 루틴 병합이 진단 중에 롤백을 취소하지 않도록 잠급니다.

Staging을 프로덕션으로 승격

스테이징 환경을 실행 중인 경우 아무것도 푸시하지 않고 테스트된 스테이징 빌드를 프로덕션으로 배치할 수 있습니다.

프로젝트 개요를 열고 Staging 섹션을 찾습니다.
스테이징이 프로덕션보다 앞서면 Promote to production이 나타납니다.
클릭하고 확인합니다.

확인을 주의 깊게 읽어보세요. Orbit에는 두 가지 다른 승격 동작이 있으며 서로 바꿀 수 없습니다. 프로젝트 개요에서 승격하면 같은 커밋에서 새로운 프로덕션 빌드가 트리거되고 프로덕션 환경 변수와 프로덕션 빌드 명령을 사용합니다. 스테이징 아티팩트는 재사용되지 않습니다. 상세 페이지에서 특정 스테이징 배포를 승격하면 스테이징 빌드가 재빌드 없이 즉시 라이브로 간다고 명확하게 표시됩니다. 스테이징과 프로덕션 환경 변수가 다르면 첫 번째 경로는 테스트한 것과 다른 아티팩트를 생성합니다.

Orbit은 또한 당신을 위해 승격할 수 있습니다. Settings의 Auto-promote staging은 스테이징이 15분마다 확인되는 건강한 스테이징의 시간 수 후에 스테이징을 프로덕션으로 승격하고 smoke tests를 통과합니다.

롤백 후

리포지토리에서 근본 원인을 수정하고 새 커밋을 푸시합니다. 이는 정상적인 빌드를 트리거하고 새로운 라이브 버전이 됩니다. 배포를 잠갔으면 먼저 잠금을 해제하세요. 그렇지 않으면 푸시가 건너뛰어집니다.

프로젝트 Activity 탭은 롤백과 발생한 다른 모든 것을 기록하므로 누가 언제 무엇을 롤백했는지의 감사 기록이 있습니다.

얼마나 멀리 롤백할 수 있는지 제한하는 것

롤백은 아티팩트가 여전히 존재해야 합니다. 두 가지 설정이 이를 제어합니다:

당신의 플랜의 배포 기록 창: Launch에서 7일, Liftoff에서 30일, Apex에서 90일.
프로젝트의 Artifact retention 설정으로, 환경당 성공한 아티팩트의 개수를 10에서 500까지 유지하며 기본값은 50입니다.

현재 라이브 배포의 아티팩트는 둘 다에 관계없이 항상 유지됩니다.

하루에 여러 번 배포하면 일 수가 아니라 아티팩트 수가 당신이 먼저 도달할 한계입니다. 50개의 배포는 한 주일일 수 있습니다. 인시던트 중에 상한선을 발견하기보다는 Artifact retention을 높입니다.