A계획은 단계로 그룹화된 작업의 순서가 정해진 집합입니다. 코드를 작성하기 전에 해당 계획을 승인해야 합니다.
작업이 특정한 순서로 여러 차례 변경되어야 하거나, 어떤 부분을 확정하기 전에 전체 접근 방식을 미리 확인하고 싶을 때 계획을 활용하세요.
라이프사이클
계획 수립은 별도의 단계이며, 즉각적인 변환 과정이 아닙니다.
- **계획 수립이 시작됩니다.**아키텍트가 코드베이스를 분석하여 단계와 작업을 초안으로 작성합니다.
- **초안을 검토합니다.**이 시점은 전체 시스템에서 수정 비용이 가장 저렴한 지점입니다.
- 승인, 수정 또는 초기화승인하면 실행을 위해 배포되고, 수정하면 피드백과 함께 다시 전달되며, 초기화하면 계획 수립을 처음부터 다시 시작합니다.
- 실행작업은 단계 경계를 준수하며 순서대로 실행됩니다.
승인과 동시에 실행하거나, 먼저 승인한 뒤 나중에 실행할 수도 있습니다.
초기화 대신 수정하기
계획이 거의 완성되었을 때 수정을 통해 아키텍트가 코드베이스에 대해 파악한 내용을 유지하면서 피드백을 반영할 수 있습니다. 초기화하면 그 정보가 모두 삭제되고 처음부터 다시 시작됩니다.
전체 접근 방식이 잘못된 경우에는 초기화하고, 접근 방식은 올바른데 세부 내용이 맞지 않는 경우에는 수정하세요. 수정이 훨씬 저렴하며, 거절된 계획의 내용도 사라지지 않고 다음 시도의 입력 자료로 활용됩니다.
실행 중인 계획 제어하기
진행 중인 계획은 일시 중지, 재개 또는 취소할 수 있으며, 각 단계별 진행 상황을 실시간으로 확인할 수 있습니다. 또한 계획을 복제할 수도 있는데, 이는 효과가 입증된 구조를 반복적으로 사용하는 실용적인 방법입니다. 예를 들어 두 번째 서비스에 동일한 마이그레이션을 적용하는 경우가 해당합니다.
완료된 계획은 활성 뷰의 가독성을 유지하기 위해 보관될 수 있습니다.
작업당 하나의 pull request가 아니라 하나의 pull request만 존재합니다.
계획에 포함된 작업 각각이 별도의 pull request를 생성하지 않습니다. 작업들은 각자 고유한 브랜치에서 작업한 뒤 공통된레인 브랜치; 해당 브랜치는 작업이 조건을 충족하면 기본 브랜치에 대한 단일 풀 요청으로 승격됩니다.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘따라서 전체 변경 내용을 한눈에 확인한 뒤에 하나의 기능을 한 번에 검토할 수 있으며, 반쪽짜리 단계를 일일이 승인할 필요가 없습니다.
교차 프로젝트 계획은 예외입니다. 레인과 다른 프로젝트에 속한 작업은 별도로 승격되므로 각 리포지토리마다 하나의 pull request가 생성됩니다. 하나의 pull request는 두 개의 리포지토리를 포괄할 수 없습니다.
단계 및 병렬 처리
단계는 순서를 정의할 뿐 병렬 실행을 보장하지 않습니다. 단계 내의 작업은 가용 용량이 허용하는 경우 병렬로 실행될 수 있지만, 다음 단계는 현재 단계가 완료될 때까지 대기합니다.
병렬 실행이 가능한 작업이 10개이고 에이전트 슬롯이 1개인 계획에서도 작업은 순차적으로 실행됩니다. 구조 자체가 용량을 창출하는 것은 아니며, 자세한 내용은용량 및 에이전트 슬롯.
계획 또는 작업?
선택은 사용자가 직접 결정하며,단계별 작업 계획또는하나의 실행 가능한 작업라우팅 단계에서 수행되는 작업입니다. 어떠한 요소도 귀하의 요청을 분석하여 대신 결정하지 않습니다.
검토 가능성이 기준입니다: 동료가 한 번에 읽을 수 있는 pull request는 작업으로 간주되고, 여러 개의 순차적 변경이 필요한 경우에는 계획으로 분류됩니다.
규모가 매우 큰 작업에 대해 작업으로 잘못 판단하는 것이 더 위험한 오류입니다. 작업은 진행 도중에 범위를 초과하여 불필요한 리소스 낭비가 발생할 수 있기 때문입니다. 반면 계획으로 잘못 판단하면 꼭 필요하지 않은 승인 단계만 추가될 뿐입니다.
배포 게이트
계획에는 해당 결과물이 다음 단계로 넘어가기 전에 충족되어야 할 조건을 관리하는 배포 게이트가 포함될 수 있습니다. 자세히 보려면품질 게이트.