Coroid에는 4가지 작업 단위가 있습니다. 이 단위들은 서로 중첩되며, 적절한 단위를 선택하는 것은 주로 작업의 규모와 동시에 실행해야 할 양에 따라 결정됩니다.
| 단위 | 규모 | 완료 시점 |
|---|---|---|
| 작업 | 하나의 변경 사항 | 하나의 pull request |
| 계획 | 기능을 단계별로 구현하기 | 전체 계획을 위한 하나의 pull request |
| 스프린트 | 일정 기간 동안 진행되는 작업 블록 | 해당 작업들에서 생성된 결과물 |
| 레인 | 병렬로 진행되는 작업 흐름 | 계획된 작업이 통합되는 브랜치 |
스프린트 · 2주
단계 1
작업결제 양식작업카드 유효성 검사단계 2
작업주문 요약단독 작업
작업날짜 파싱 오류 수정작업
최소 단위입니다. 하나의 작업은 하나의 pull request를 생성하는 단위이며 실제로 실행되는 대상입니다. 계획, 스프린트, 레인은 모두 작업을 구성하는 방식일 뿐입니다.
결과물을 한 단락으로 설명할 수 있고 리뷰어가 한 번에 내용을 확인할 수 있다면, 그것이 바로 작업입니다.
계획
특정 순서에 따라 여러 차례의 변경이 필요한 작업은 계획이 됩니다. 즉, 코드 작성 전에 승인하는 단계별로 그룹화된 작업의 순서 집합입니다.
다음과 같은 경우에 계획을 사용하세요:
- 후속 단계가 이전 단계에 의존하는 경우
- 실제 구현에 착수하기 전에 전체 접근 방식을 확인하고 싶은 경우
- 작업이 단순한 변경이 아닌 기능인 경우
계획을 승인하는 것은 시스템 내에서 가장 비용이 적게 드는 개입 지점입니다. 여기서 접근 방식을 거부하는 데 드는 시간은 1분에 불과하지만, 작업이 세 번 실행된 후에 거부하면 세 번의 실행 비용이 발생합니다.
계획이 저장소에 도달하는 과정
계획의 작업들은 각각 별도의 pull request를 생성하지 않습니다. 각 작업은 자체 브랜치에서 작업한 뒤 공유된레인 브랜치로 병합되며, 해당 브랜치가 기본 브랜치에 대해 단일 풀 요청으로 승격됩니다.
레인 브랜치
계획 작업이 통합되는 곳
pull request 하나
한 번 검토된 통합 기능
main
기본 브랜치
레인과 다른 프로젝트의 작업은 단독으로 승격되므로, 교차 프로젝트 계획은 저장소별로 pull request를 생성합니다.
따라서 완성된 기능을 한 번에 리뷰할 수 있으며, 반쪽짜리 단계별로 개별적으로 승인할 필요가 없습니다.
예외적인 경우는 여러 프로젝트에 걸쳐 진행되는 작업입니다. 레인과 다른 프로젝트에 속한 작업은 별도로 처리되므로, 프로젝트 간 계획은 저장소별로 pull request를 생성합니다. 이는 불가피한 현상으로, pull request는 두 개의 저장소에 걸쳐 존재할 수 없기 때문입니다.
스프린트
자체적인 지표와 일정이 정해진 시간 제한형 작업 컨테이너입니다. 스프린트는 '이 기능이 어떻게 구현되는가'가 아니라 '이 기간 동안 무엇을 하고 그 결과는 어떤가'를 다룹니다.
팀의 작업을 특정 기간에 조율할 때는 스프린트를, 하나의 기능을 세분화할 때는 계획을 사용하세요. 둘은 상호 대체 관계가 아니며, 스프린트 내에 여러 계획에 속하는 작업이 포함될 수 있습니다.
레인
레인은 계획의 병렬 작업이 통합되는 곳입니다. 작업들은 기본 브랜치가 아닌 레인의 브랜치를 대상으로 하므로 여러 에이전트가 충돌 없이 동시에 작업을 진행할 수 있으며, 조건을 충족하면 단일 pull request로 승격됩니다.
계획이 중점을 두는 것은순서반면 레인이 중점을 두는 것은동시성및통합입니다. 여러 에이전트를 활용할 수 있고 반드시 순차적으로 처리할 필요가 없는 작업이 있다면, 레인을 통해 동시에 실행된 뒤 하나의 리뷰 가능한 변경 사항으로 도출할 수 있습니다.
선택하기
중요한 것은 원하는 풀 요청의 수가 아니라, 결과물을 리뷰할 가치가 있기 전까지 얼마나 많은 작업이 진행되어야 하는가입니다. 작업과 계획 모두 하나의 풀 요청으로 도출됩니다.
- 리뷰어가 한 번에 읽을 수 있는 하나의 변경 사항인가요?예 → 작업.
- 전체적으로 의미를 갖추려면 여러 차례의 순차적 변경이 필요한가요?예 → 계획. 레인을 통해 허용되는 범위 내에서 작업들을 병렬로 실행합니다.
스프린트는 이 모든 것과 별개로 계획 및 보고를 위한 계층으로 작동합니다.
릴리스의 역할
릴리스는릴리스는 통합 이후의 배포 기록이며, 별도의 작업이나 계획, 스프린트, 처리 단계가 아닙니다. 이는 저장소 커밋을 고정하고 해당 커밋에 계획된 작업이 포함되었는지 확인하며, 각 환경에서의 배포 시도 과정을 추적합니다. 하나의 릴리스에는 여러 스프린트의 작업이 포함될 수 있고, 하나의 스프린트에서 여러 릴리스가 생성될 수도 있습니다. 처리 단계 승격은 pull request를 생성하지만, 이를 통해 검증된 배포물이 자동으로 만들어지는 것은 아닙니다.
동시 실행 가능한 작업량을 결정하는 요인
구조가 아니라 용량이 중요합니다. 병렬 처리가 가능한 작업이 10개이고 에이전트 슬롯이 1개라면 해당 작업들은 순차적으로 실행됩니다. 자세한 내용은용량 및 에이전트 슬롯.