Orbit 릴리스

The Releases tab turns your git tags into a version history you can read: every tagged deployment, in order, with its commit, its author, its status and a link straight to the tag in your repository.

Releases 탭은 git 태그를 읽을 수 있는 버전 기록으로 변환합니다. 태그된 모든 배포가 순서대로 표시되며, 각 커밋, 작성자, 상태 및 저장소의 태그로 바로 이동하는 링크가 포함됩니다.

Releases의 위치

Orbit을 열고 프로젝트를 클릭한 다음 프로젝트 탭 스트립의 Deployments 그룹 아래에서 Releases를 선택합니다. 페이지는 Releases라는 제목이며 태그 기반 배포로 설명됩니다. git 태그가 태그 패턴과 일치하면 릴리스가 생성됩니다.

인접한 Deployments 탭은 태그된 것이든 아니든 모든 빌드를 나열합니다. Releases는 필터링된 보기입니다. 버전으로 표시한 것들만 표시됩니다.

태그 패턴 설정

Releases는 패턴으로 시작됩니다. Settings를 열고 Git tag deploys 카드를 찾은 다음 v* 또는 release-*과 같은 glob을 입력합니다. 비워두면 태그 배포가 완전히 비활성화되며, 이것이 필드의 플레이스홀더가 v* (disabled)을 읽는 이유입니다.

패턴이 설정되면, 일치하는 태그를 푸시하면 프로덕션에 배포되고 결과가 릴리스로 기록됩니다. 패턴이 없으면 Releases 탭에 태그를 푸시하고 Settings에서 패턴을 설정하라는 빈 상태 메시지가 표시됩니다.

태그 패턴은 프로덕션 브랜치로의 푸시와 함께 프로덕션으로 가는 두 번째의 명시적 경로를 제공합니다. 병합의 부작용이 아닌 의도적인 행위가 되기를 원하는 팀들은 종종 브랜치 자동 배포를 끄고 태그 전용으로 프로덕션을 실행합니다.

릴리스 생성

당신 쪽에서 전체 흐름은 두 개의 git 명령어입니다:

git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0

Orbit이 태그를 받아 패턴과 비교하고, 태그된 커밋을 프로덕션에 배포하며, 릴리스를 기록합니다. 이것은 Building 배지와 함께 이 탭에 나타나고, 배포되면 Deployed로 이동하거나 빌드가 오류나면 Failed로 이동합니다.

경량 태그보다는 주석이 달린 태그를 사용하세요. 주석이 달린 태그는 메시지, 작성자, 날짜를 포함하며, 이 모든 것이 릴리스에 나타납니다.

기존 배포에 태그 지정

릴리스를 얻기 위해 git 태그를 푸시할 필요는 없습니다. 모든 배포는 세부 정보 페이지에서 태그할 수 있으며, 버전 번호처럼 보이는 태그는 여기에서 선택됩니다.

버전 형태의 태그는 1.4, 1.4.0, v1.4.0 또는 v2.0.0-rc1과 같은 것입니다. 다른 모든 것은 일반 배포 태그로 남아 있으며 릴리스 항목을 생성하지 않습니다.

이것은 패턴을 설정하기 전에 릴리스가 나갔거나, 핫픽스가 수동으로 배포되었고 어쨌든 버전 기록에 포함하려는 경우의 탈출구입니다.

릴리스 읽기

각 릴리스 행은 다음을 표시합니다:

릴리스의 제목인 태그
커밋 및 그 메시지
작성자, by name 형식으로 표시
이동한 환경, 유형별로 색상 코딩됨
상태 배지: Deployed, Building 또는 Failed
저장소의 태그로 이동하는 View on 링크
기본 배포로 이동하는 링크

View on 링크는 공급자별 올바른 위치를 가리킵니다. GitHub의 릴리스 페이지, GitLab의 태그 페이지, 또는 Bitbucket의 해당 태그에서의 소스입니다.

릴리스 노트

저장소에서 태그의 릴리스를 발행하면, 노트는 가져와지고 배포에 첨부되어, Releases 탭은 복사본을 두 개 유지하도록 강요하지 않고 저장소에 작성한 동일한 텍스트를 전달합니다.

이렇게 하면 저장소가 릴리스 노트를 작성할 수 있는 단일 장소가 됩니다. 한 번 작성하고, 기여자들이 이미 있는 곳에서 작성하면, 여기에 나타납니다.

태그당 하나의 릴리스

목록은 태그로 중복 제거됩니다. 태그가 두 번 이상 배포된 경우, 예를 들어 첫 번째 빌드가 실패하고 재시도한 경우, 해당 태그에 대한 가장 최근 배포만 표시됩니다.

상단의 카운터는 총합을 제공하고, 목록은 프로젝트의 전체 기록보다는 최근 태그된 배포의 충분한 창을 포함합니다.

Releases를 잘 사용하기

브랜치가 아닌 병합에서 태그하세요. 실제로 프로덕션 브랜치에 있는 커밋에 태그를 지정하세요. 병합되지 않은 피쳐 브랜치 커밋에 태그를 지정하면 main의 어떤 것에도 해당하지 않는 릴리스가 생성됩니다.

시맨틱 버전을 사용하세요. 올바르게 정렬되고, 버전 형태로 인식되며, 모두가 이미 읽는 방법을 알고 있습니다.

태그를 이동하지 마세요. 기존 태그를 새 커밋에 다시 지정하는 것은 이 목록의 릴리스와 저장소의 태그가 배포된 것에 대해 동의하지 않는다는 의미입니다. 대신 새로운 패치 버전을 생성하세요.

태그 푸시는 패턴과 일치하면 프로덕션으로 직접 배포됩니다. 그 외의 것은 우회하지 않습니다. 배포 잠금, 승인 요구사항 및 동결 기간은 설정된 대로 계속 적용됩니다. 하지만 실수로 푸시된 태그는 초안이 아닌 프로덕션 배포라는 의미입니다. 사용 가능한 게이트는 Deploying Your Project를 참조하세요.

릴리스 롤백

릴리스는 배포이므로, 하나를 롤백하는 것은 일반적인 롤백 흐름입니다. 배포를 열고 이전의 성공적인 것을 복원하세요. Rolling Back a Deployment을 참조하세요.

그 후 나쁜 태그를 삭제하기 보다는 수정을 위해 새 태그를 생성하세요. 실패한 릴리스가 기록에 남아 있다는 것은 유용한 정보이며 불필요한 것이 아닙니다.

문제 해결

태그가 푸시되었지만 릴리스가 나타나지 않았습니다. Settings의 패턴을 확인한 다음, 태그가 실제로 원격에 도달했는지 확인하세요. git push origin v1.4.0은 한 태그를 푸시합니다. git push 단독으로는 아무것도 푸시하지 않습니다.

릴리스가 Failed를 표시합니다. 브랜치 푸시와 정확히 동일하게 빌드가 실패했습니다. 배포를 열고 로그를 읽으세요: Reading Build Logs.

View on 링크가 없습니다. 프로젝트에 연결된 저장소가 없으므로 링크할 곳이 없습니다. 하나를 연결하세요: Connecting a GitHub Repository를 참조하세요.

수동으로 태그된 배포가 나열되지 않습니다. 태그가 버전 형태가 아닙니다. v1.4.0과 같은 것으로 이름을 변경하세요.

릴리스 노트가 비어 있습니다. 노트는 저장소에서 발행된 릴리스에서 가져옵니다. 릴리스 객체가 없는 일반 태그에는 가져올 노트가 없습니다.

다음으로 갈 곳

Deploying Your Project: 전체 배포 주기 및 게이트
Rolling Back a Deployment: 릴리스가 잘못되었을 때
Orbit Timeline Annotations: 릴리스가 변경한 것을 기록하려면