이 시스템은 작업과 계획을 검토 완료된 pull request로 전환합니다. 이들이 병합되면릴리스가 다음 질문에 답합니다:해당 작업 중 어떤 것이 어디서 실행되고 있으며, 그곳에 배포하는 것이 안전한가요?
Coroid는 정확한 Git 커밋 하나를 지정하여 스테이징부터 프로덕션까지의 환경을 따라 해당 커밋을 추적합니다. 이 커밋은 이미 배포 브랜치에 있을 수도 있고, Coroid가 열린 pull request들을 하나의 릴리스 pull request로 묶어 병합 커밋을 릴리스로 만들 수도 있습니다. 각 단계에서 Coroid는 커밋을 검사하고 사용자가 요청한 승인을 수집하며, CI/CD가 보고하는 배포 내역을 기록합니다. Coroid는 절대 자체적으로 릴리스가 배포되었다고 표시하지 않습니다. 파이프라인이나 외부 배포를 기록하는 담당자가 이를 확인해야만 합니다.
Coroid 공장
작업 또는 계획
에이전트가 계획, 구축 및 테스트를 수행합니다.
Pull Request
증거를 바탕으로 검토됩니다.
병합됨
사용자 또는 저장소 규칙에 의해 병합됩니다.
릴리스
릴리스
고정된 단일 커밋
스테이징
검사 · 승인 · 배포
프로덕션
검사 · 승인 · 배포
1분 만에 이해하기
- 릴리스: 하나의 커밋, 이름, 그리고 선택적 버전. 버전과 같은
2.4.0은 선택 사항이므로 태그 없이도 지속적 배포가 가능합니다. - 환경: 스테이징이나 프로덕션과 같이 사용자에게 도달하기 전의 경유지입니다. 각 프로젝트마다 자체적인 경유지와 순서가 정의됩니다.
- 롤아웃: 릴리스가 현재까지 도달한 환경들을 의미합니다.
- 작업: 릴리스를 위해 계획된 작업과 병합된 변경 사항으로, 전체 대비 완료된 비율로 표시됩니다.
- 각 환경별 4단계: 검사, 승인, 배포, 상태 확인. 릴리스 페이지는 항상 사용자가 처리해야 할 단계를 먼저 표시합니다.
- 번들: 열린 pull request들로 구성된 릴리스입니다. Coroid는 사용자가 변경할 수 있는 순서대로 이들을 하나의 릴리스 브랜치에 병합한 뒤 하나의 릴리스 pull request를 생성합니다. 번들 릴리스에는 다섯 번째 단계인번들, 검사 전에 실행됩니다.
릴리스 개요 확인하기
열기릴리스은 모든 프로젝트의 메인 사이드바에 위치하며, 또는 특정 프로젝트의릴리스탭에서 확인할 수 있습니다.현재 실행 중, 상단에 표시되는 내용은 마지막으로 확인된 배포 내역을 기준으로 각 환경에서 실행 중인 버전과 시작한 담당자입니다. 목록에는 각 릴리스의 작업 진행 상황, 환경별 롤아웃 현황, 그리고 상태가 나타납니다. 탭을 이용해 진행 중인 릴리스, 배포 완료된 릴리스, 종료된 릴리스를 전환할 수 있습니다.
릴리스 페이지를 열려면 해당 릴리스를 선택하세요.
- 1상태. 릴리스의 전반적인 진행 상황입니다.
- 2출시 및 작업 과정. 지금까지 구축된 환경과 완료된 작업 내용을 확인하세요. 특정 단계를 보려면 해당 항목을 선택하십시오.
- 3단계. 선택한 환경의 네 단계입니다. 사용자가 개입해야 하는 단계가 열려 있습니다.
- 4출시되는 내용. 커밋에 확인된 병합된 변경 사항, 계획된 작업, 그리고 마지막 배포 이후의 커밋들입니다.
롤아웃 트랙도 전환 기능을 제공합니다. 해당 환경을 선택하면 그 환경의 4단계를 확인할 수 있습니다. 페이지는 릴리스가 아직 도달하지 못한 첫 번째 환경부터 열리므로 다음에 수행할 작업이 바로 보입니다.
각 환경별 4단계
- 1검증 단계
Coroid
정확한 커밋에 대해 품질 검사가 실행되며, 필수 체크리스트 항목이 확인됩니다.
- 2승인 단계
귀사의 팀
규칙에 명시된 담당자들이 이 환경을 위한 해당 커밋을 승인합니다.
- 3배포 단계
귀사의 CI/CD
Coroid 또는 자동으로 시작된 귀사의 파이프라인이 배포를 수행하고 결과를 보고합니다.
- 4상태 확인 단계
Coroid
확인된 배포 이후에 캐니어리 검사가 환경을 모니터링합니다.
검사.선택하기검사 실행. Coroid는 프로젝트의 릴리스 유효성 검증용 Quality Graph를 해당 커밋에 대해 실행하여 연결된 모든 변경 사항이 해당 커밋 내에 포함되어 있는지 확인합니다. 해당 환경에 필요한 체크리스트 항목도 모두 완료되어야 합니다. 릴리스를 막는 요인이 있으면 이 단계에 그 내용이 표시됩니다. 커밋이나 연결된 변경 사항을 수정하면 이전 검사 결과는 무효가 되며, 다시 검사를 실행하라는 안내가 나타납니다.
승인.검사가 통과되면 규칙에서 허용한 담당자들이 승인할 수 있습니다. 이 단계에는 필요한 승인 수와 해당 역할이 표시됩니다. 규칙에서 릴리스 노트 승인을 요구하는 경우 노트 승인도 여기서 이루어집니다.
배포.검사와 승인이 완료되면 릴리스는 해당 환경에 배포될 준비가 됩니다. Coroid가 해당 환경의 GitHub Actions나 GitLab CI/CD에 연결되어 있다면 소유자나 관리자가배포하기…를 선택하면 Coroid가 해당 커밋에 대한 파이프라인을 시작합니다. 그렇지 않으면 파이프라인이 자체적으로 배포를 수행한 뒤 결과를 보고합니다. 어느 쪽이든 성공이 확인되어야만 이 단계가 녹색으로 표시됩니다.
상태 확인.배포가 성공적으로 완료되면, 캐니어리형 Quality Graph가 설정되어 있다면 Coroid가 이를 실행합니다. 캐니어리형 검사가 통과되면 해당 환경의 상태가 정상으로 판단됩니다. 실패할 경우주의가 필요함가 표시되고 복구 옵션이 제공됩니다. 캐니어리형 검사가 없으면 상태는 가정에 의해 정상이 아닌 '알 수 없음'으로 유지됩니다.
상태의 의미
| 상태 | 의미 |
|---|---|
| 초안 | 아직 커밋이 지정되지 않았습니다. 번들 릴리스는 릴리스 pull request가 병합될 때까지 초안 상태로 유지됩니다. |
| 준비 중 | 커밋이 지정되었지만 아직 일부 단계에서 검사나 승인이 누락되었습니다. |
| 차단됨 | 검사가 완료되었으나 무언가가 릴리스를 막고 있습니다. |
| 준비됨 | 최소 한 개 환경에 대해 검사와 승인이 완료되었지만 아직 배포되지 않았습니다. |
| 배포 중 | 배포가 진행 중입니다. |
| 부분 배포됨 | 릴리스가 일부 환경에는 도달했지만 모든 환경에는 도달하지 못했습니다. |
| 배포 완료 | 릴리스가 모든 환경에 도달했습니다. |
| 실패 또는 취소됨 | 릴리스가 중단되어 더 이상 진행되지 않습니다. |
| 이력 기록 | 배포 증거가 존재하기 전에 생성된 것으로, 배포 증명으로 간주되지 않습니다. |
준비됨릴리스 pull request가 배포를 의미하는 것은 아닙니다. 확인된 배포만이 롤아웃 트랙에서 릴리스를 앞으로 진행시킵니다.
워크플로우
프로젝트의 릴리스를 설정하세요
프로젝트당 한 번만 이 작업을 수행하세요.릴리스,릴리스 설정, 그리고 프로젝트를 선택하세요.
-
에서환경, 단계를 추가하고 순서를 정하세요. 예를 들어 프로덕션보다 스테이징을 먼저 배치하세요.
-
에서승인 규칙, 각 환경에 대한 규칙을 게시하세요: 승인 횟수, 해당 역할, 체크리스트 항목 등입니다. 규칙이 게시되기 전에는 환경이 검사를 통과할 수 없습니다.
-
에서배포 파이프라인, Coroid가 배포를 시작할지 아니면 사용자 파이프라인이 시작할지 선택하세요. 그런 다음 보고용 토큰을 생성하여 CI/CD가 Coroid에게 배포된 내용을 알릴 수 있도록 하세요.
-
에서버전 관리, 각 릴리스의 버전이 어디서 오는지 선택하고, 각 환경에 버전 URL을 할당하여 Coroid가 거기서 실행되는 내용을 확인할 수 있도록 하세요.
릴리스 설정각 화면을 안내해 주며,빌드에 버전을 포함시키세요가 버전이 앱에 어떻게 전달되는지 보여줍니다.
계획된 작업 출시하기
함께 출시될 항목을 미리 알고 있을 때 이 기능을 사용하세요.
- 커밋이 고정되기 전에 미리 릴리스를 생성하세요. 초기 상태는 초안입니다.
- 해당 릴리스에 포함할 작업에 대상 릴리스를 설정하세요. 이 작업들은 계획된 작업, 작업이 완료되면 작업 막대가 채워집니다.
- 작업이 병합되면,세부 정보 편집을 선택하여 커밋을 출시용으로 지정하세요. Coroid가 해당 커밋에 포함된 병합된 변경사항을 확인합니다.
- 첫 번째 환경에 대해 네 단계를 거친 후 다음 환경에도 동일하게 적용하세요.
열린 pull request 묶기
Coroid 또는 팀에서 대기 중인 여러 pull request가 함께 출시되어야 할 때 이 기능을 사용하세요.
- 결제 총액 수정하기#12검사 통과
- 주문 내보내기 기능 추가하기#15Coroid 작업승인됨
- 검색 인덱스 재작업하기#18초안
- Coroid의 순서는 가장 안정적인 항목을 먼저 배치합니다. 사용자가 체크하고 순서를 변경할 수 있습니다.
- 하나의 릴리스 브랜치에 풀 리퀘스트가 순서대로 병합됩니다.
- 하나의 릴리스 pull request입니다. 이가 병합되면 해당 커밋이 바로 배포됩니다.
릴리스 pull request를 Merge 커밋으로 병합하면, 제공업체에서 해당 pull request 묶음이 모두 병합된 것으로 인식합니다.
- 선택하세요새 릴리스, 프로젝트를 선택한 후열린 pull requests. 이 옵션을 사용하려면 GitHub 또는 GitLab 저장소가 필요하므로, Coroid에서 호스팅되는 프로젝트는 커밋을 출시합니다.
- Coroid는 배포 브랜치로 들어가는 열린 pull request를 가장 안전한 순서대로 나열합니다. Coroid가 생성한 pull request는 해당 작업 또는 계획으로 표시됩니다. Coroid는 제공업체와 자체 리뷰에서 이미 확인한 내용—체크, 리뷰, 크기, 충돌, 여러 pull request가 접근하는 파일—을 고려하여 우선순위를 정합니다. 초안, 실패한 체크, 요청된 변경사항, 포크에서 온 pull request는 제외하며 그 이유도 함께 표시합니다.
- 대기시킬 항목의 선택을 해제하고 화살표를 사용해 순서를 변경하세요. 다른 pull request를 기반으로 하는 pull request(스택형 pull request 또는 "#12에 의존"이라고 명시된 경우)는 항상 그 뒤에 배치됩니다.
- 선택하세요릴리스 생성. Coroid는
release/<version>를 배포 브랜치에서 생성하고, pull request를 순서대로 병합한 뒤, 각 항목을 나열하고 링크하는 단일 릴리스 pull request를 엽니다. - pull request와 릴리스 브랜치 간에 충돌이 발생하면,번들단계에서 중단되고 관련 파일이 표시됩니다.Coroid로 해결을 선택하여 개발자 에이전트가 이를 병합하고 작업 내에서 충돌을 해결하도록 하거나,제외하기 를 선택하여 해당 항목 없이 계속 진행하세요.릴리스 pull request를 검토한 후
- 릴리스 pull request를 리뷰하고 다음을 사용해 병합하세요merge commit. 그러면 제공업체는 묶인 모든 pull request를 병합된 상태로 표시합니다. Coroid는 merge commit을 릴리스 커밋으로 지정하고, 묶인 pull request를 릴리스에 포함되는 항목으로 기록하며, 아직 열려 있는 항목은 릴리스 pull request 링크와 함께 닫습니다.
- 각 환경에서 평소처럼 네 단계를 진행하세요.
스쿼시 또는 리베이스 병합도 가능하지만, 제공업체는 원래 pull request를 병합된 상태로 표시하지 않습니다. 대신 Coroid가 주석을 달아 해당 항목을 닫습니다.
지속적 배포를 위해 병합된 항목을 바로 출시할 때 이 기능을 사용하세요.
선택하세요
- 새 릴리스커밋을 선택하세요. 보통 배포 브랜치의 최신 커밋입니다.에서
- 비교 대상와 비교원한다면 이름과 버전을 비워두세요. Coroid는 날짜와 짧은 커밋 정보를 기반으로 릴리스 이름을 지정하며, 프로젝트의 버전 소스가 버전을 채워줍니다. 모든 릴리스에는 다음 빌드 번호도 할당됩니다.
- 이름과 버전은 비워 두어도 됩니다. Coroid는 날짜와 짧은 커밋 해시를 사용해 릴리스 이름을 지정하고, 프로젝트의 버전 소스가 버전을 채웁니다. 모든 릴리스에는 다음 빌드 번호도 지정됩니다.
- 릴리스를 생성하고 네 단계를 진행하세요.
만약 파이프라인이 병합될 때마다 배포하거나, 누군가가 Coroid의 승인 없이 수동으로 배포한다면, 여전히 각 배포 내역을 보고할 수 있습니다. 보고된 커밋에 대해 릴리스가 존재하지 않을 경우, Coroid는 해당 커밋에 대한 관찰된 릴리스를 생성하며, 이는 Coroid의 검증을 통과하지 못했음을 명확히 표시합니다. 이때 사용되는 버전은 파이프라인에서 보고한 버전이거나, Coroid가 프로젝트의 버전을 할당하는 경우 다음 버전입니다(1.4.1이후1.4.0), 그리고 다음 빌드 번호가 됩니다.
긴급 수정사항 배포하기
소유자 또는 관리자는 다음 기능을 활성화할 수 있습니다:이것은 핫픽스입니다릴리스를 생성할 때, 수정사항의 전체 커밋을 고정하고 정상적인 일정으로 처리할 수 없는 이유를 명시하세요. 핫픽스는 각 환경의 핫픽스 규칙을 따르며, 이 경우 승인 절차가 간소화될 수 있습니다. 품질 검증 및 필수 체크리스트 항목은 여전히 적용되며, 핫픽스는 소유자와 관리자만 승인할 수 있습니다.
문제 발생 시 복구하기
헬스 체크 단계에서 다음과 같은 결과가 나타나면주의가 필요함,헬스를 영향을 받은 환경에서 열고, 이전의 안정적인 커밋을 선택하여 재배포하세요.복구 및 릴리스 트레인에서는 보고할 수 없는 파이프라인을 포함한 여러 옵션에 대해 설명합니다.
채팅 또는 편집기에서 이용하기
채팅 어시스턴트와 Coroid의 MCP 서버는 동일한 릴리스 도구를 제공합니다: 릴리스 목록 확인 및 상세 정보 조회, 커밋 선택, 배포 예정 내용 미리보기, 릴리스 준비, 열린 릴리스 pull request 묶기, 검증 실행, 승인 요청, 배포 요청 및 메모 초안 작성. 묶기, 승인 및 배포 작업은 반드시 사람의 확인이 필요합니다. 자세한 내용은채팅 어시스턴트및Coroid를 MCP 서버로 사용하기.
여러 프로젝트를 함께 릴리스하기
릴리스 트레인은 함께 배포되어야 하는 여러 프로젝트의 릴리스를 순차적으로 그룹화한 것으로, 예를 들어 API와 이를 기반으로 하는 애플리케이션이 해당됩니다. 자세한 내용은복구 및 릴리스 트레인.
Coroid의 기능 및 한계
- Coroid는 커밋을 고정하고 검증하며 기록합니다. 저장소와 CI/CD는 빌드 및 배포를 담당합니다.
- pull request를 묶을 때, Coroid은 릴리스 브랜치와 릴리스 pull request를 생성합니다. 하지만 사용자를 대신해 릴리스 pull request를 병합하지 않습니다.
- Coroid는 연결된 파이프라인이 있고 소유자 또는 관리자가 배포를 요청할 때에만 파이프라인을 시작합니다.
- 배포 요청만으로는 충분하지 않습니다. 롤아웃 과정은 파이프라인에서 성공을 확인하거나 누군가가 검증된 외부 배포 내역을 기록해야만 진행됩니다.
- 릴리스 노트는 사용자가 편집하고 승인하는 초안입니다. Coroid는 이를 어디에도 게시하지 않습니다.
- 스프린트는 계획 기간일 뿐 배포 경계가 아닙니다. 하나의 스프린트에서 여러 릴리스가 나올 수 있으며, 하나의 릴리스에 여러 스프린트의 작업이 포함될 수도 있습니다.