계획

하나의계획은 단계로 그룹화된 작업의 순서화된 집합입니다. 코드를 작성하기 전에 이를 승인합니다.

작업이 특정한 순서로 여러 차례 변경되어야 하거나, 어떤 작업을 시작하기 전에 전체 접근 방식을 확인하고 싶을 때 계획을 활용하세요.

라이프사이클#

계획 수립은 별도의 단계이며, 즉각적인 변환 과정이 아닙니다.

1. 계획 수립이 시작됩니다.요청이 자격 검증을 통과하면 아키텍트가 코드베이스를 살펴보고 단계와 작업을 초안으로 작성합니다. 요청에 첨부 파일이 있거나 SDLC 워크플로우를 사용한 경우를 제외하면 계획 수립은 자동으로 시작되며, 그렇지 않으면 계획을 생성하거나 준비를 마칠 때 시작됩니다.
2. 초안을 검토하세요.이 단계는 전체 시스템에서 비용이 가장 적게 드는 개입 지점입니다.
3. 승인, 수정 또는 초기화하기승인하면 실행을 위해 배포되고, 수정하면 피드백과 함께 다시 보내지며, 초기화하면 계획 수립을 처음부터 다시 시작합니다.
4. 실행작업은 단계 경계를 준수하며 순서대로 실행됩니다.

승인과 동시에 실행하거나, 먼저 승인한 뒤 나중에 실행할 수도 있습니다.

초기화하는 대신 수정하기#

계획이 거의 완성되었을 때 수정을 통해 아키텍트가 코드베이스에 대해 얻은 정보를 유지하고 피드백을 반영할 수 있습니다. 초기화하면 그 정보가 모두 삭제되고 처음부터 다시 시작됩니다.

전체 접근 방식이 잘못된 경우에만 초기화하고, 접근 방식은 올바른데 세부 내용이 맞지 않는 경우에는 수정하세요. 수정은 비용이 훨씬 적게 들며, 거절된 계획의 내용도 손실되지 않고 다음 시도의 입력값으로 활용됩니다.

실행 중인 계획 제어하기#

진행 중인 계획은 일시 중지, 재개 또는 취소할 수 있으며, 단계별 진행 상황을 확인할 수 있습니다. 계획은 복제도 가능한데, 이는 효과적으로 검증된 구조를 반복하는 방법입니다. 예를 들어 두 번째 서비스에 마이그레이션을 적용하는 경우가 해당됩니다.

완료된 계획은 활성 뷰를 명확하게 유지하기 위해 보관될 수 있습니다.

작업당 하나가 아닌 하나의 pull request#

계획의 작업들은 각각 별도의 pull request를 열지 않고, 자체 브랜치에서 작업한 뒤 공유된레인 브랜치에 병합됩니다. 작업이 요건을 충족하면 해당 브랜치는 기본 브랜치에 대한 단일 풀 요청으로 승격됩니다.

따라서 전체 변경 내용을 한눈에 확인한 뒤에 기능을 한 번에 검토할 수 있으며, 반쪽짜리 단계를 하나씩 승인하는 번거로움을 피할 수 있습니다.

교차 프로젝트 계획은 예외입니다. 해당 레인과 다른 프로젝트에 속한 작업은 별도로 상승 처리되므로 각 저장소마다 하나의 pull request가 생성됩니다. 하나의 pull request는 두 개의 저장소에 걸쳐 존재할 수 없습니다.

기본 브랜치가 변경될 때#

계획은 수 시간 동안 실행될 수 있으며, 그동안 팀에서는 기본 브랜치에 계속 변경 사항을 병합합니다. 계획은 시작 시점의 기본 브랜치를 기준으로 구축, 테스트 및 검토되었습니다. pull request가 준비될 무렵에는 해당 브랜치가 더 이상 병합 대상이 아닐 수 있습니다.

계획이 실행되기 시작하면 Coroid는 기본 브랜치의 최신 커밋을 계획의기준선으로 기록합니다. 계획의 pull request가 병합되기 전에 Coroid는 다시 기본 브랜치를 확인합니다. 계획에서 다루지 않은 파일을 포함하여 파일 내용의 모든 변경이 이에 해당합니다. 새로운 인증 체계나 보안 규칙으로 인해 올바른 코드가 잘못된 것으로 판단될 수 있지만, 병합 충돌이 발생하지 않아도 Coroid는 기다리지 않습니다.

기본 브랜치가 변경된 경우,승인 및 병합버튼은 비활성화되고, 승격 검토 화면에 새로운 커밋과 변경된 파일 목록이 표시됩니다. 이때 원하는 작업을 선택할 수 있습니다:

• 새로운 main 브랜치 수락하기(기본 브랜치의 이름과 동일) — 이 변경 사항은 현재 작업에 영향을 주지 않습니다. Coroid는 누가 어떤 커밋을 수락했는지와 그 이유를 기록하며, 해당 커밋이 새로운 기준선이 됩니다. 읽는 도중에 브랜치가 다시 변경되면 Coroid는 이를 거부하고 더 최신 커밋을 먼저 보여줍니다. 표시되지 않은 항목은 절대 수락되지 않습니다.
• 병합 및 재검증하기— Coroid는 기본 브랜치를 레인 브랜치에 병합하며 충돌이 있으면 이를 해결합니다. 그런 다음 개발자, QA 및 리뷰어 단계를 다시 거쳐 계획의 수락 기준 및 상위 커밋과 비교하여 검증합니다. 검증이 완료될 때까지 승인은 보류 상태로 유지됩니다. 이때 비로소 새로운 커밋이 기준선이 됩니다. 병합 또는 재검증에 실패하면 결정권은 다시 사용자에게 돌아갑니다.

기본 설정은 일시 중지입니다. 프로젝트에서 병합 및 재검증 방식을 선택하면 Coroid가 사용자를 기다리지 않고 바로 작업을 시작합니다. 자세한 내용은리포지토리 및 브랜치 설정. 재검증에는 에이전트 시간이 소요됩니다.

처음부터 다시 시작된 계획은 새로운 기준선을 기록하므로, 그 시점의 베이스 브랜치를 기준으로 실행됩니다. 이전 시도에서 생성된 증거는 기록에 남지만 새로운 시도의 현재 상태로 간주되지는 않습니다.

강제 병합이 확인 단계도 건너뛰며, 해당 요구사항을 입력한 사유를 기록합니다. 자세한 내용은병합.

단계와 병렬 처리#

단계는 순서를 정의할 뿐 병렬 실행을 보장하지 않습니다. 단계 내 작업은 가용 용량이 허용될 경우 병렬로 실행될 수 있지만, 다음 단계는 현재 단계가 완료될 때까지 대기합니다.

병렬 실행이 가능한 작업이 10개이고 에이전트 슬롯이 하나뿐인 경우에도 해당 작업들은 순차적으로만 실행됩니다. 구조 자체가 용량을 창출하는 것은 아니며, 이 점을 참고하십시오.용량과 에이전트 슬롯.

계획 또는 작업?#

새 작업 양식에서 다음 항목을 선택하세요:계획또는작업아래의생성 방식, 또는 그대로 두세요자동자동으로 설정하고 Qualification이 결정하도록 하세요. 하나 이상의 프로젝트에 걸치는 작업은 항상 계획으로 처리됩니다. 특정 경로를 선택했지만 Qualification이 다른 경로를 추천하는 경우, 실제로 생성되기 전에 해당 추천 내용을 확인할 수 있습니다.

판단 기준은 검토 가능성입니다: 동료가 한 번에 읽을 수 있는 분량의 pull request는 작업이며, 순차적인 변경이 여러 번 필요한 경우에는 계획이 됩니다.

실제로 규모가 큰 작업을 작업으로 잘못 분류하는 것이 더 위험한 실수입니다. 작업의 범위가 중간에 부족해져서 작업이 낭비될 수 있기 때문입니다. 계획으로 잘못 분류하면 꼭 필요하지 않은 승인 단계가 추가될 뿐입니다.

배포 게이트#

계획에는 그 결과물이 진행되기 전에 충족되어야 할 조건을 관리하는 배포 게이트를 설정할 수 있습니다. 자세한 내용은품질 게이트.

관련 항목#

• 작업, 계획, 스프린트 및 레인
• 스프린트
• 사양
• 출처