프로젝트 배포하기

리포지토리가 연결되면 Orbit은 프로덕션 브랜치에 매번 푸시할 때마다 배포됩니다: 커밋을 클론하고, 의존성을 설치하고, 빌드를 실행하고, 출력을 패키징하고, 서빙을 시작합니다. 이 가이드는 전체 배포 주기, 수동으로 배포를 트리거하는 방법, 배포가 라이브로 갈 수 있는 시기를 결정하는 컨트롤을 다룹니다.

자동 배포 작동 방식

Settings에서 Production branch로 설정된 브랜치에 모든 푸시는 배포를 트리거합니다. 그 다음 Git에서 Orbit은:

1. GitHub, GitLab 또는 Bitbucket에서 푸시 이벤트를 수신합니다.
2. 배포를 큐에 넣고 빌드 슬롯을 할당합니다.
3. 정확한 커밋에서 리포지토리를 클론합니다.
4. 빌드 캐시가 플랜에서 사용 가능한 경우 캐시된 node_modules를 복원합니다.
5. 설치 명령어(npm ci, yarn install 또는 pnpm install, lockfile에서 감지됨)를 실행합니다.
6. 빌드 명령어를 실행합니다.
7. 출력 디렉토리를 배포 아티팩트로 패키징하고 업로드합니다.
8. 환경을 전환하여 새 아티팩트를 서빙합니다.

배포 상세 페이지는 이를 명명된 Build phases로 표시합니다: Clone, Cache restore, Install, Cache save, Build, Upload, Done. 대부분의 프로젝트는 1~3분 안에 완료됩니다.

배포 상태

빌드 진행 상황 보기

프로젝트 Overview는 Latest build 패널에서 실시간 스트리밍 로그와 함께 현재 빌드를 보여줍니다. Full details를 클릭하여 배포 상세 페이지를 열면, 빌드 진행률 바, 예상 남은 시간, 큐 위치, 단계별로 분류된 빌드 타임라인을 추가로 볼 수 있습니다.

플랜에서 동시에 빌드 한 개 이상을 허용하고 모두 바쁜 경우, 페이지가 명확히 알려줍니다: 몇 개의 동시 빌드 슬롯이 사용 중인지 표시하고 하나가 비워지면 배포를 자동으로 시작합니다. Orbit으로 이동한 후 Queue에서 모든 프로젝트에 걸쳐 진행 중인 모든 빌드를 볼 수 있습니다.

수동으로 배포 트리거하기

새 커밋을 푸시하지 않고 배포하는 방법은 4가지입니다.

최신 커밋 다시 배포하기

1. 프로젝트를 엽니다.
2. Deployments 탭을 엽니다.
3. 원하는 배포를 클릭하여 상세 페이지를 엽니다.
4. Retry build를 클릭합니다. 캐시된 의존성이 만료되었다고 의심되면 More retry options을 클릭한 후 Retry with cleared cache를 사용합니다.

지금 배포

Deployments 탭의 Deploy now 버튼은 프로덕션 브랜치의 현재 헤드의 새로운 빌드를 큐에 넣습니다.

배포 예약하기

배포를 향후 시간으로 예약할 수 있습니다. Orbit은 예약할 때 커밋을 스냅샷하므로 나중에 실행되는 빌드는 승인한 코드이며, 그 사이에 병합된 다른 코드가 아닙니다.

배포 훅

배포 훅은 무언가가 POST 요청을 보낼 때 빌드를 큐에 넣는 비밀 URL입니다. 헤드리스 CMS, cron 작업 또는 CI 파이프라인에서 다시 빌드할 때 사용합니다. 프로젝트의 Hooks 탭에서 설정합니다. 배포 훅을 통해 배포 트리거하기를 참조하세요.

빌드 설정

Orbit은 대부분의 프로젝트에 합리적인 기본값을 감지합니다. Settings에서 Build settings를 통해 이 중 어떤 것이든 재정의합니다:

자동 감지된 값을 유지하려면 필드를 비워둡니다. 프레임워크별 값 및 첫 배포가 실패하는 원인이 되는 실수를 포함한 전체 내용은 빌드 명령어 및 출력 디렉토리 설정하기를 참조하세요.

배포가 허용되는 시점 결정하기

Orbit에는 여러 독립적인 게이트가 있습니다. 모두 Settings에 있습니다.

배포 잠금

잠금을 사용하여 인시던트, 유지보수 기간 또는 코드 프리징 중에 프로덕션을 동결합니다.

1. 프로젝트를 엽니다.
2. Lock deploys를 클릭합니다.
3. 선택적 이유를 추가합니다.

잠금 중에는 푸시 트리거 배포가 조용히 스킵되고 배너에 Production deploys are locked이 당신의 이유와 함께 표시됩니다. 수동 배포는 계속 작동합니다. 이는 의도적입니다: 잠금은 실수로 인한 배포를 중지하지만, 배포하려는 수정은 중지하지 않습니다. Unlock deploys를 클릭하여 해제합니다.

프로덕션 승인 필수

Deploy protection 아래에서 Require approval for production을 켭니다. 그러면 푸시 트리거 프로덕션 배포는 Awaiting approval에서 일시 정지되고, 누군가가 배포를 열어서 Approve 또는 Reject를 클릭할 때까지 진행되지 않습니다. 패널 배포 및 배포 훅은 영향을 받지 않습니다.

스테이징 성공 먼저 필요

Require staging success before production은 스테이징 환경이 동일한 커밋을 성공적으로 배포할 때까지 푸시 트리거 프로덕션 배포를 보류합니다. 누군가는 여전히 수동으로 승인하여 대기를 건너뛸 수 있습니다.

CI 필수 검사

CI required checks 아래에서 자신의 CI에 배포를 게이트합니다. GitHub에서는 쉼표로 구분된 Actions 작업 이름을 입력하고 모두 통과해야 합니다. GitLab에서는 비어있지 않은 값이 전체 파이프라인을 대기합니다. CI 실패는 Orbit 배포를 자동으로 취소합니다.

배포 동결 일정

Deploy freeze schedule은 승인된 창 외부의 푸시 트리거 배포를 차단합니다: 주말 차단, 허용된 시간 범위 또는 둘 다. 모든 시간은 UTC입니다. 수동 배포 및 배포 훅은 영향을 받지 않습니다.

필요하지 않은 빌드 스킵하기

• Ignored paths: 쉼표로 구분된 글로브 패턴입니다. 푸시의 모든 파일이 일치하면 빌드가 스킵됩니다. *.md,docs/**은 문서 커밋이 배포를 트리거하지 않도록 합니다.
• Branch ignore patterns: 일치하는 브랜치의 푸시는 완전히 스킵됩니다. dependabot/*,renovate/*은 일반적인 경우입니다.
• Git tag deploys: 푸시된 태그가 v*과 같은 글로브와 일치할 때 프로덕션에 배포합니다.

빌드 캐시

Orbit은 Liftoff 및 Apex 플랜에서 빌드 간 node_modules을 캐시합니다. 캐시된 설치가 사용되면, 배포에 Cache hit 배지가 표시되고 설치 단계가 훨씬 더 빨라집니다. 콜드 빌드는 대신 Cold build를 표시합니다.

전체 재설치를 강제하려면 Settings로 이동한 후 Clear build cache를 열고 확인합니다. 각 환경의 다음 배포는 처음부터 전체 설치를 실행합니다.

배포가 잘못된 경우

Orbit은 나쁜 배포를 라이브로 두기보다는 감지할 수 있습니다:

• Auto-rollback on failure는 프로덕션 배포가 실패하면 자동으로 마지막 정상 배포를 복원합니다.
• Health check는 모든 프로덕션 배포 후 선택한 경로를 가져옵니다. 15초 이내에 2xx가 아닌 응답이 이전 정상 배포를 복원합니다.
• Smoke tests는 각 성공적인 배포 후 최대 10개의 경로에 대해 GET 요청을 실행하고 통과 또는 실패를 기록합니다. 자동 롤백과 결합하면, 실패한 스모크 테스트가 배포를 롤백합니다.

배포를 직접 취소하려면 배포 롤백하기를 참조하세요. 빌드가 실패한 이유를 파악하려면 실패한 빌드 문제 해결을 참조하세요.