이 페이지는 나머지 문서에서 참조하는 기준 페이지입니다. 각 실행 단계를 명시하여 다른 문서에서 해당 작업이 발생하는 위치를 정확히 설명할 수 있도록 합니다.
경로
- 1
사양 정의무엇을 구축할 것인지와 그 작동 여부를 확인하는 방법
설계자귀하가 수정 가능 - 2계획 수립
코드 작성 전에 검토되는 순차적 단계들
설계자귀하가 승인 - 3
구현 및 빌드격리된 작업 공간에서 작성된 코드와 테스트
개발자 - 4
검증 수행귀하의 테스트 스위트와 함께 품질 검증 절차도 포함됨
QA - 5
리뷰 진행차이점에 대한 자동화된 리뷰 과정
리뷰어 - 6풀 리퀘스트 생성
귀하의 저장소 내 브랜치에 위치하며 귀하의 승인을 기다림
귀하가 병합
검증 실패나 수정 가능한 리뷰 결과는 pull request가 생성되기 전에 개발자에게 재작업으로 다시 전달됩니다.
이 단계들은 작업이 실행되는 두 가지 방식에서 동일하게 적용됩니다. 표준 모드에서는 플랫폼이 작업을 한 단계씩 다음 단계로 이동시킵니다. 코디네이터 모드에서는 계획 에이전트가 코디네이터로서 작업에 계속 관여하며, 각 단계를 적절한 에이전트에게 할당하고 각 결과에 따라 다음 진행 방향을 결정합니다. 여기에는 작업을 다시 전달하는 경우도 포함됩니다. 어느 쪽이든 각 단계는 자체 검증 절차를 통해 종료됩니다. 자세한 내용은에이전트 역할을 참고하여 두 모드의 차이점을 확인하세요.
사양
Coroid는 사용자의 문장으로부터 시작하지 않습니다. 먼저 사용자의 설명을사양으로 변환합니다. 즉, 무엇을 구축할지, 어떤 부분은 명시적으로 범위에서 제외될지, 그리고 작업이 성공했는지를 판단하는 수락 기준을 정의합니다.
이것이 중요한 이유는 수락 기준이 이후 검증 단계에서 테스트의 기준이 되기 때문입니다. 모호한 사양으로는 결과물을 판단하기 어렵습니다.
작업의 사양은 실행 시작 전에 작업의사양탭에서 확인하고 편집할 수 있습니다.
이사양 기반 개발 가이드에서는 테스트 가능한 기준을 작성하는 방법, 범위 경계를 설정하는 방법, 그리고 계획·구현·검토 단계에 걸쳐 동일한 성공 정의를 유지하는 방법을 설명합니다.
계획
소규모 변경을 넘어서는 경우, 사양은계획으로 발전합니다. 즉, 단계별로 그룹화된 순서가 정해진 작업 목록입니다. 코드 작성 전에 이 계획을 승인해야 합니다.
계획을 거부하는 것은 비용이 저렴하며 접근 방식이 잘못된 경우 올바른 선택입니다. 코드 작성 후에 거부하는 것은 비용이 많이 듭니다. 바로 이 단계에서 사용자의 판단력이 가장 큰 영향력을 발휘합니다.
구축
에이전트는 저장소를 격리된 작업 공간에 복제한 뒤 그곳에서 작업합니다. 코드를 읽고 변경 사항을 작성하며 테스트를 작성하거나 업데이트합니다.
이 작업 공간은 작업별로 별도로 생성되며 일회용입니다. 에이전트의 작업이 기본 브랜치에 영향을 주지 않으며, 동시에 실행되는 두 작업이 서로의 진행 중인 작업을 볼 수 없도록 합니다.
검증
먼저 사용자 고유의 테스트 스위트가 실행됩니다. 이는 팀에서 이미 중요하다고 판단한 사항을 반영하므로 가장 신뢰할 수 있는 지표입니다.
이 외에도품질 게이트가 조직에서 설정한 규칙을 적용합니다. 커버리지 임계값, 린팅, 미리보기 배포 환경에서의 브라우저 테스트, 그리고보안보호 기능까지 포함됩니다. 블로킹 게이트는 작업을 중단시키고, 권고형 게이트는 발견 사항을 기록한 뒤 작업을 계속 진행시킵니다.
리뷰
리뷰어 에이전트는 동료가 하는 것과 같이 변경 내용을 검토하고 발견 사항을 도출합니다. 수정 가능한 발견 사항은 재작업을 위해 다시 전달되고, 나머지는 pull request에 첨부되어 사용자가 확인할 수 있습니다.
바로 이런 이유로 Coroid의 pull request는 이미 검토를 거친 상태로 제공됩니다. 이는 사용자의 검토를 대체하기 위함이 아니라, 사용자의 검토가 최초의 검토가 되지 않도록 하기 위함입니다.
풀 요청
브랜치가 푸시되면 pull request가 기본 브랜치를 대상으로 열리며, 여기에 변경 사항, 테스트 결과, 검증 결과, 리뷰 발견 사항이 포함됩니다. 만약 코드가 이미 작업 요구사항을 충족한다면 푸시할 내용이 없으므로 QA가 변경되지 않은 코드를 검증하고 작업은 pull request 없이 종료됩니다.
Coroid의 작업 자동화는 여기서 종료됩니다. 병합은 사용자가 직접 처리합니다.
병합 이후
배포를 준비하려면릴리스을 열어 출시할 정확한 커밋을 준비하세요. 하나의 배포에는 여러 개의 병합된 풀 요청, 직접 커밋, 또는 Coroid 외부에서 병합된 작업이 포함될 수 있습니다. 배포 게이트와 승인 절차는 해당 커밋 및 특정 환경을 대상으로 적용됩니다. 파이프라인이 이를 배포하며, Coroid는 배포 완료로 표시하기 전에 관찰된 성공 결과나 명시적 증명을 기록합니다.COMPLETED로 표시되거나 병합된 pull request만으로는 배포가 완료되었음을 증명할 수 없습니다.
작업 상태
작업의 상태는 위 과정에서 현재 어디에 위치해 있는지를 알려줍니다.
| 상태 | 의미 |
|---|---|
PENDING | 승인됨, 사용 가능한 에이전트 슬롯을 기다리는 중 |
IN_PROGRESS | 현재 활발히 작업 중 |
PENDING_REVIEW | 작업이 완료되고 검토를 마쳤으며, 통합 또는 승인을 기다리는 중 |
COMPLETED | 작업이 완료되었으며 배포는 별도로 추적됨 |
NEEDS_HUMAN_REVIEW | Coroid는 혼자서 진행할 수 없으며 사용자의 질문을 기다리고 있습니다. |
PAUSED | 일시적으로 중지됨, 재개 가능 |
FAILED | 실행을 완료할 수 없음 |
CANCELLED | 사용자에 의해 중지됨 |
WONT_FIX | 작업을 수행하지 않고 의도적으로 종료됨 |
처리량을 결정하는 요인
하나의에이전트 슬롯한 번에 하나의 작업만 실행됩니다. 슬롯은 병렬로 처리되는 작업량을 결정할 뿐, 개별 작업의 완료 시간을 단축시키지는 않습니다. 작업 소요 시간은 변경 사항의 규모와 테스트 스위트 실행 시간에 따라 결정됩니다.
다음
에이전트 역할— 각 작업 단계를 담당하는 에이전트를 확인하세요.릴리스환경을 거쳐 병합 후 프로세스를 진행하기 위해 사용됩니다.