릴리스

이 시스템은 작업과 계획을 검토된 풀 리퀘스트로 전환합니다. 이들이 병합되면릴리스가 다음 질문에 답합니다:해당 작업 중 어떤 것이 어디에서 실행되고 있으며, 그곳에 배포하는 것이 안전했는지 확인할 수 있습니다.

릴리스는 단일 Git 커밋을 지정하고 해당 커밋을 스테이징 및 프로덕션과 같은 환경을 통해 추적합니다. 이 커밋은 이미 배포 브랜치에 있을 수도 있고, Coroid가 먼저 열려 있는 풀 리퀘스트들을 하나의 릴리스 pull request로 묶어 병합 커밋을 릴리스로 만드는 경우도 있습니다. 각 단계에서 Coroid는 커밋을 검사하고 사용자가 요청한 승인을 수집하며, CI/CD가 보고하는 배포 정보를 기록합니다. Coroid는 절대 스스로 릴리스가 배포되었다고 표시하지 않습니다. 파이프라인이나 외부 배포를 기록하는 담당자가 이를 확인해야만 합니다.

1분 안에 이해하는 개념#

• 릴리스: 단일 커밋, 이름, 그리고 선택적 버전입니다. 버전은 다음과 같습니다: 2.4.0버전은 선택 사항이므로 태그 없이도 지속적 배포가 가능합니다.
• 환경: 스테이징이나 프로덕션처럼 사용자에게 도달하기까지 거치는 단계입니다. 각 프로젝트마다 자체적인 단계와 순서가 정의됩니다.
• 롤아웃: 릴리스가 현재까지 도달한 환경들을 의미합니다.
• 작업: 릴리스를 위해 계획된 작업과 병합된 변경 사항으로, 완료된 작업 수 대비 전체 작업 수로 표시됩니다.
• 각 환경별 4단계 프로세스: 검사, 승인, 배포, 그리고 상태 확인입니다. 릴리스 페이지는 항상 처리해야 할 단계를 먼저 보여줍니다.
• 번들: 개방형 pull request를 기반으로 생성된 릴리스입니다. Coroid는 이를 하나의 릴리스 브랜치로 병합하며, 사용자가 원하는 순서로 변경할 수 있고, 이후 하나의 릴리스 pull request가 생성됩니다. 번들 릴리스의 경우 다섯 번째 단계가 추가로 존재합니다.번들단계가 존재합니다.

릴리스를 한눈에 확인하기#

열기릴리스메인 사이드바에서 모든 프로젝트의 또는 특정 프로젝트의릴리스탭을 통해 확인할 수 있습니다. 목록에는 각 릴리스의 작업 진행 상황, 환경별 롤아웃 상태 및 상태가 표시됩니다. 탭을 이용해 진행 중인 릴리스, 배포 완료된 릴리스, 종료된 릴리스를 전환할 수 있습니다.

릴리스를 선택하여 해당 페이지를 열어보세요.

롤아웃 트랙도 전환 수단으로 활용됩니다. 특정 환경을 선택하면 해당 환경의 4단계를 확인할 수 있습니다. 페이지는 릴리스가 아직 도달하지 못한 첫 번째 환경부터 열리므로 다음 조치 내용이 바로 눈에 들어옵니다.

각 환경별 4단계#

검사.선택하기검사 실행. Coroid가 프로젝트의 릴리스 유효성 검증용 Quality Graph를 해당 정확한 커밋에 대해 실행하여 연결된 모든 변경 사항이 해당 커밋 내에 포함되어 있는지 확인합니다. 해당 환경에 필요한 체크리스트 항목도 모두 완료되어야 합니다. 릴리스를 차단하는 요인이 있으면 해당 단계에 그 내용이 표시됩니다. 커밋이나 연결된 변경 사항이 바뀌면 이전 검사 결과는 무효가 되며, 다시 검사를 실행하라는 안내가 나타납니다.

승인.검사가 통과되면 규칙에 따라 허용된 인원이 승인할 수 있습니다. 이 단계에서는 필요한 승인 수와 역할이 표시됩니다. 규칙상 승인된 릴리스 노트가 필요한 경우 여기서 함께 승인됩니다.

배포.검사와 승인이 완료되면 해당 환경에 대한 릴리스 준비가 끝납니다. 만약 Coroid가 해당 환경의 GitHub Actions 또는 GitLab CI/CD와 연동되어 있다면, 소유자나 관리자가…로 배포를 선택하면 Coroid가 해당 정확한 커밋에 대한 파이프라인을 시작합니다. 그렇지 않으면 파이프라인이 자동으로 배포를 수행한 뒤 결과를 보고합니다. 어느 쪽이든 성공이 확인되어야만 해당 단계가 녹색으로 변합니다.

상태 확인.배포가 성공적으로 완료되면, 캐니어리형 Quality Graph가 설정되어 있다면 Coroid가 이를 실행합니다. 캐니어리 검사가 통과되면 해당 환경의 상태가 정상으로 판단됩니다. 실패할 경우주의가 필요함으로 표시되며 복구 옵션이 제공됩니다. 캐니어리 검사가 없으면 상태는 가정에 의해 정상이 아닌 '미확인' 상태로 유지됩니다.

상태의 의미#

준비됨‘준비됨’ 상태만으로는 배포된 것으로 간주되지 않습니다. 확인된 배포가 있어야만 릴리스가 배포 경로를 따라 진행됩니다.

워크플로우#

프로젝트용 릴리스 설정하기#

프로젝트당 한 번만 수행하세요.릴리스메뉴에서릴리스 설정을 선택한 뒤 프로젝트를 지정하세요.

1. 에서환경, 환경 순서를 정의하고 배치하세요. 예를 들어 Staging 환경을 Production 환경 앞에 배치합니다.

2. 에서승인 규칙, 각 환경별 승인 규칙을 정의하세요. 필요한 승인 횟수, 해당 역할, 체크리스트 항목 등을 지정합니다. 규칙이 정의되기 전까지는 환경의 검사가 통과될 수 없습니다.

3. 에서배포 파이프라인, Coroid이(가) 배포를 시작할지 아니면 사용자의 파이프라인이 배포를 처리할지를 선택하세요. 그런 다음 보고용 토큰을 생성하여 CI/CD이(가) Coroid에 배포 내용을 알릴 수 있도록 합니다.

4. 에서버전 관리, 각 릴리스의 버전 출처를 선택하고 환경별로 버전 URL을 지정하여 Coroid이(가) 해당 환경에서 실행되는 버전을 확인할 수 있도록 하세요.

릴리스 설정각 화면을 차례로 안내해 드립니다.빌드에 버전 포함하기버전이 애플리케이션에 어떻게 전달되는지 보여줍니다.

계획된 작업 배포하기#

함께 배포해야 할 항목이 미리 정해져 있을 때 사용하세요.

1. 커밋이 고정되기 전에 미리 릴리스를 생성할 수 있습니다. 이 경우 초안 형태로 시작됩니다.
2. 해당 릴리스에 포함할 작업의 대상 릴리스를 설정하세요. 해당 작업들은 계획된 작업에 표시되며, 작업이 완료될 때마다 진행률 막대가 채워집니다.
3. 작업이 병합되면,세부 정보 편집을(를) 선택하고 배포할 커밋을 지정하세요. Coroid이(가) 해당 커밋에 포함된 병합된 변경 사항을 확인합니다.
4. 첫 번째 환경부터 네 단계를 차례로 진행한 후 다음 환경으로 넘어가세요.

열려 있는 풀 요청 묶기#

Coroid 또는 팀에서 대기 중인 여러 풀 요청을 함께 배포해야 할 경우 이 기능을 사용하세요.

1. 을 선택하세요새 릴리스, 프로젝트를 선택한 뒤열려 있는 풀 요청을 선택하세요. 이 옵션을 사용하려면 GitHub 또는 GitLab 저장소가 필요하며, Coroid에서 호스팅되는 프로젝트의 경우 커밋 형태로 릴리스됩니다.
2. Coroid가 배포 브랜치에 있는 열려 있는 풀 요청을 가장 안전한 순서대로 나열합니다. Coroid가 생성한 pull request는 작업 또는 계획으로 표시됩니다. Coroid는 제공업체 및 자체 리뷰에서 이미 확인한 내용—검사 결과, 리뷰 내용, 크기, 충돌 여부, 여러 풀 요청이 공유하는 파일 등—을 종합적으로 고려합니다. 초안 상태인 항목, 검사에 실패한 항목, 변경 요청이 반영된 항목, 포크에서 온 풀 요청은 제외하며 그 이유도 함께 안내합니다.
3. 배포를 미룰 항목의 선택을 해제하고 화살표를 이용해 순서를 조정하세요. 다른 풀 요청을 기반으로 하는 풀 요청(중첩된 pull request 또는 '#12번에 의존'이라는 설명이 있는 경우)은 항상 그 이전에 배치됩니다.
4. 을 선택하세요릴리스 생성. Coroid가release/<version>를 배포 브랜치에서 생성하고 풀 요청을 순서대로 병합한 뒤, 각 풀 요청을 목록화하고 링크하는 릴리스 pull request를 열어줍니다.
5. 만약 pull request가 릴리스 브랜치와 충돌하면,번들단계에서는 해당 파일들이 표시됩니다. 다음을 선택하세요:Coroid로 해결하기를 통해 개발자 에이전트가 이를 병합하고 작업 내에서 충돌을 해결하게 하거나,제외하기를 선택하여 해당 항목 없이 계속 진행하세요.
6. 릴리스 pull request를 검토한 뒤 이를병합 커밋으로 병합하세요. 그러면 제공업체가 번들링된 모든 pull request를 병합된 상태로 표시합니다. Coroid는 병합 커밋를 릴리스 커밋으로 지정하고, 번들링된 풀 리퀘스트를 배포 대상으로 기록한 뒤, 릴리스 pull request에 대한 링크와 함께 아직 열려 있는 항목들을 닫습니다.
7. 평소와 같이 각 환경에 대해 네 단계를 차례로 수행하세요.

Squash 또는 rebase 병합 방식도 사용할 수 있지만, 제공업체는 원본 풀 리퀘스트를 병합된 상태로 표시하지 않습니다. 대신 Coroid가 댓글을 통해 이를 닫습니다.

main 브랜치에 있는 내용 배포하기#

병합된 내용을 즉시 배포하고 싶을 때 연속 배포에 사용하세요.

1. 을(를) 선택하세요새 릴리스를 선택하고 일반적으로 배포 브랜치의 최신 커밋을 지정하세요.
2. 에서비교 대상, 교체하려는 환경을 선택하세요. Coroid이(가) 해당 환경에서 실행 중인 버전과 새 커밋 사이의 풀 리퀘스트 및 커밋 목록을 표시하고 검증 가능한 항목만 선별합니다.
3. 이름과 버전을 비워둬도 괜찮습니다. Coroid이(가) 날짜와 짧은 커밋 정보를 기반으로 릴리스 이름을 지정하며, 프로젝트의 버전 출처에서 버전 정보가 자동으로 채워집니다. 모든 릴리스에는 다음 빌드 번호도 할당됩니다.
4. 릴리스를 생성한 후 네 단계를 따르세요.

사용자의 파이프라인이 Coroid의 승인 없이도 병합 시마다 배포를 수행하더라도 배포 내역을 보고할 수 있습니다. 보고된 커밋에 대한 릴리스가 존재하지 않으면 Coroid이(가) 해당 릴리스를 ‘관찰된 릴리스’로 생성하며, Coroid의 검사를 통과하지 못했음을 명확히 표시합니다.

긴급 수정 사항 배포하기#

소유자 또는 관리자가이것은 핫픽스입니다를 활성화할 수 있으며, 릴리스 생성 시 수정 사항의 전체 커밋을 고정하고 일반적인 절차로는 처리할 수 없는 이유를 명시하세요. 핫픽스는 각 환경의 핫픽스 규칙을 따르므로 필요한 승인 횟수가 줄어들 수 있습니다. 다만 품질 검사와 필수 체크리스트 항목은 여전히 적용되며, 핫픽스를 승인할 수 있는 권한은 소유자와 관리자에게만 있습니다.

문제 발생 시 복구하기#

상태 점검 단계에서주의가 필요함,상태영향을 받는 환경에서 이전의 안정적인 커밋을 선택하여 재배포하세요.복구 및 릴리스 트레인해당 옵션들을 설명하며, 여기에는 결과를 보고할 수 없는 파이프라인도 포함됩니다.

채팅 또는 편집기에서 바로 이용 가능#

채팅 어시스턴트와 Coroid의 MCP 서버에는 동일한 릴리스 도구가 탑재되어 있습니다: 릴리스 목록 확인 및 상세 정보 조회, 커밋 선택, 배포 예정 내용 미리보기, 릴리스 준비, 열린 풀 리퀘스트 번들링, 검사 실행, 승인 요청, 배포 요청 및 메모 초안 작성 등입니다. 번들링, 승인 및 배포 작업은 반드시 사람의 확인이 필요합니다. 자세한 내용은채팅 어시스턴트및Coroid의 MCP 서버.

여러 프로젝트를 함께 릴리스하기#

릴리스 트레인은 함께 순차적으로 배포되어야 하는 여러 프로젝트의 릴리스를 묶어 관리합니다. 예를 들어 API와 이를 기반으로 하는 애플리케이션이 해당됩니다. 자세히 보기복구 및 릴리스 트레인.

Coroid의 기능과 한계#

• Coroid는 커밋을 고정하고 검사하며 기록합니다. 저장소와 CI/CD가 빌드 및 배포를 담당합니다.
• 풀 리퀘스트를 번들링할 때 Coroid가 릴리스 브랜치와 릴리스 pull request를 생성하지만, 릴리스 pull request를 병합해주지는 않습니다.
• Coroid는 연결된 파이프라인이 있고 소유자 또는 관리자가 배포를 요청할 때에만 파이프라인을 시작합니다.
• 배포 요청만으로는 충분하지 않습니다. 롤아웃 과정은 파이프라인이 성공을 확인하거나 누군가 검증된 외부 배포 내역을 기록해야만 진행됩니다.
• 릴리스 노트는 사용자가 편집하고 승인하는 초안 형태이며, Coroid가 이를 외부에 게시하지는 않습니다.
• 스프린트는 계획 기간일 뿐 배포 경계가 아닙니다. 하나의 스프린트에서 여러 릴리스가 나올 수 있으며, 하나의 릴리스에 여러 스프린트의 작업이 포함될 수도 있습니다.

관련 항목#

• 릴리스 설정
• 배포 이벤트 및 CI 설정
• 빌드 과정에 버전 정보 포함하기
• 복구 및 릴리스 트레인
• 스프린트
• 작업, 계획, 스프린트 및 진행 단계
• 품질 및 리뷰 증거