Coroid는 단순한 빌드 단계가 아닌 전체 소프트웨어 라이프사이클을 모델링합니다. 대부분의 프로세스는 자동으로 실행되며, 중요도가 충분히 높은 작업에 한해 선택적으로 활성화할 수 있는 단계도 존재합니다.
선택적 SDLC 워크플로우
에서새 작업양식의 고급 설정 항목에 체크박스가 있습니다:
SDLC 워크플로우 사용(선택 사항)— 계획 수립 전에 의도와 사양을 검토할 수 있습니다. 이 옵션을 끄면 요약 내용을 바탕으로 직접 계획을 시작할 수 있습니다.
기본적으로 이 기능은기본적으로 비활성화되어 있습니다. 비활성화하면 요약 내용이 승인된 후 바로 계획 수립이 시작됩니다.자격 검증이 기능을 활성화하면 먼저 두 가지 산출물을 생성하고 승인받아야 합니다:
- 의도— 작업의 목적과 그 뒤에 숨겨진 결정 사항 및 가정을 기록한 내용입니다.
- 사양— 작업 범위, 제외 항목 및 수용 기준을 명시한 내용입니다.
이 두 가지가 승인된 후에야 계획 수립이 시작됩니다.
이 기능을 활성화해야 하는 경우
잘못된 결과물을 만드는 데 드는 비용이 높거나, 요청을 한 사람이 직접 계획을 검토하지 않을 예정이거나, 요약 내용에 미리 확정된 가정이 포함된 경우 이 기능을 활성화하세요.
요약 내용이 이미 명확하다면 이 기능을 끄세요. 일상적인 작업에 불필요한 승인 단계를 추가하면 오히려 불편함만 초래됩니다. 어쨌든계획 승인단계는 여전히 적용됩니다.
다섯 단계의 프로세스
전체 라이프사이클은 다섯 단계로 구성되며, 각 단계에서 다음 단계에서 활용할 수 있는 증거 자료가 생성됩니다.
| 단계 | 수행되는 작업 | 상태 |
|---|---|---|
| 정의 | 모호한 요청이 승인된 의도, 결정 사항, 가정 및 성공 기준으로 구체화됩니다. | 베타 |
| 시각화 | 선택적 UI 컨셉을 구체화하여 디자인 가이드로 승인받습니다. | 베타 |
| 구현 | 계획이 세분화되고 에이전트가 이를 실행합니다. | 사용 가능 |
| 입증하기 | 요구사항이 작업, 검사 결과, 리뷰 내용 및 풀 리퀘스트 변경사항에 매핑됩니다. | 사용 가능 |
| 개선하기 | 모니터링, 문제 해결 및 평가를 통해 회귀 현상을 다음 주기의 작업으로 전환합니다. | 사용 가능 |
- 정의 단계승인된 의도, 결정 사항, 가정 및 성공 기준베타
- 시각화 단계선택적 UI 컨셉으로, 디자인 가이드로 승인됩니다.베타
- 배포 단계계획이 세분화되고 에이전트들이 이를 실행합니다.사용 가능
- 입증 단계요구사항이 작업, 검사, 결과물 및 변경 사항으로 매핑됩니다.사용 가능
- 개선 단계회귀 현상은 다음 사이클의 작업이 됩니다.사용 가능
선택적계획 시작 전에 의도와 명세를 승인하려면 SDLC 워크플로우를 활성화하세요.
개선 단계가 다음 사이클로 이어집니다. 모니터링, 수정 및 평가를 통해 회귀 현상을 새로운 작업으로 전환합니다.
정의하기 및 시각화하기는 현재 활발히 개발 중인 기능입니다. 제공하기, 입증하기 및 개선하기는 체크포인트를 활성화하든 아니든 모든 작업에서 현재 실행되는 기능입니다.
아티팩트가 버전 관리되는 이유
승인은 특정 버전의 아티팩트에 연결됩니다. 승인된 아티팩트를 편집하면 합의된 내용이 자동으로 변경되는 대신 새로운 초안이 생성됩니다.
이것이 바로 승인이 의미 있는 이유입니다. '사양'에 연결되었지만 특정 버전에 연결되지 않은 승인은 나중에 문서에 적힌 내용과 상관없이 어떤 내용이든 승인하게 되며, 이는 진정한 승인이 아닙니다.
승인 역할
제품, 디자인, 기술, 보안 및 릴리스 관련 책임을 개별적으로 할당할 수 있으므로 보안 영향력을 승인하는 사람이 반드시 범위를 승인하는 사람은 아닙니다.
증거 계보
각 단계에서 증거를 생성하는 목적은 완성된 pull request를 역추적할 수 있도록 하기 위함입니다. 즉, 이 변경사항이 이 작업을 구현하며, 이 작업은 이 요구사항에서 비롯되고, 이 요구사항은 승인된 의도에서 비롯됩니다.
이러한 연쇄 관계 덕분에 자율적 배포 과정을 감사할 수 있습니다. 이 연쇄 관계가 없으면 동작하는 코드는 있지만 왜 그 코드가 요청한 코드인지에 대한 설명은 없습니다.
리뷰된 코드에서 릴리스까지
pull request는 작업 주기의 출력물입니다. 저장소 규칙에서 병합이 허용되면릴리스는 전체 커밋 SHA를 고정하고 해당 커밋에 포함된 변경사항을 기록합니다. 준비 상태 게이트는 선택된 환경에 대해 해당 정확한 커밋을 평가합니다. 승인은 게이트 스냅샷에 연결되며, 후보나 정책을 편집하면 이전의 결정이 무효화됩니다.
배포 요청 시 연결된 파이프라인에서 배포 시도가 시작됩니다. 제공업체 콜백이나 수동 증명을 통해 특정 환경에 도달한 내용을 기록하며, 배포 후 카나리아를 통해 상태를 별도로 기록합니다. 따라서 작업, pull request 및 릴리스는 각각 다른 의미를 가집니다. 완료된 작업이 코드가 프로덕션에 도달했음을 증명하는 것은 아닙니다.
이것이 계획과 어떻게 연관되는가
SDLC 워크플로우와계획은 서로 다른 체크포인트입니다:
- SDLC 워크플로우는SDLC 워크플로우는무엇을구축할지 접근 방안이 확정되기 전에 승인합니다.
- 계획은계획는어떻게구축할지 코드가 존재하기 전에 승인합니다.
두 가지 중 하나를 사용하거나 둘 다 사용하거나 아예 사용하지 않을 수도 있습니다. 둘 다 사용하는 것이 승인에 동의하지 않는 완성된 pull request를 리뷰하는 것보다 비용이 더 저렴합니다.