SDLC 워크플로우

Coroid는 빌드 단계뿐만 아니라 전체 소프트웨어 라이프사이클을 모델링합니다. 대부분의 과정은 자동으로 진행되며, 일부는 작업의 중요도가 충분히 높을 때 활성화하는 선택적 단계입니다.

선택적 SDLC 워크플로우#

에서새 작업양식의 고급 설정 항목에 체크박스가 있습니다:

SDLC 워크플로우 사용(선택 사항)— 계획 수립 전에 의도와 사양을 검토할 수 있습니다. 이 기능을 끄면 요약 내용에서 바로 계획을 시작할 수 있습니다.

이 기능은기본적으로 비활성화되어 있습니다. 비활성화하면 요약 내용이 바로 계획 수립 단계로 넘어갑니다. 활성화하면 먼저 두 가지 산출물이 생성되고 승인을 받아야 합니다:

1. 의도— 작업의 목적과 그 뒤에 숨겨진 결정 사항 및 가정을 기록한 내용입니다.
2. 사양— 범위, 제외 사항 및 수용 기준을 명시한 내용입니다.

이 두 가지가 승인된 후에야 계획 수립이 시작됩니다.

언제 이 기능을 활성화해야 할까요?#

잘못된 제품을 만드는 데 드는 비용이 높거나, 요청을 한 사람이 직접 계획을 검토하지 않는 경우, 또는 요약 내용에 기록해두고 합의하고 싶은 가정이 포함된 경우에 이 기능을 활성화하세요.

요약 내용이 이미 명확하게 정의된 경우에는 이 기능을 끄세요. 일상적인 작업에 불필요한 승인 단계는 오히려 불편함만 초래할 뿐입니다. 그리고계획 승인단계는 어차피 적용됩니다.

다섯 가지 단계#

전체 라이프사이클은 다섯 단계로 진행되며, 각 단계마다 다음 단계에서 활용할 수 있는 증거 자료가 생성됩니다.

정의하기와 시각화하기 단계는 현재 활발히 개발 중입니다. 구현하기, 증명하기, 개선하기 단계는 이 검토 기능을 활성화하든 안 하든 모든 작업에서 현재 실행되고 있습니다.

산출물에 버전 관리가 적용되는 이유#

승인은 특정 버전의 산출물에 연결됩니다. 승인된 산출물을 편집하면 기존에 합의된 내용이 silently 변경되는 대신 새로운 초안이 생성됩니다.

이것이 바로 승인의 의미를 갖게 하는 요소입니다. ‘사양’에 연결된 채로 존재하는 승인은 나중에 문서에 적힌 내용과 상관없이 언제든지 변경될 수 있으므로 진정한 승인이라 할 수 없습니다.

승인 역할#

제품, 디자인, 기술, 보안 및 배포 관련 책임을 별도로 할당할 수 있어 보안 영향을 승인하는 사람이 반드시 범위를 승인하는 사람과 일치할 필요는 없습니다.

증거 이력#

각 단계에서 증거 자료를 생성하는 목적은 완성된 pull request를 역추적할 수 있도록 하기 위함입니다: 이 변경 사항은 이 작업을 구현하며, 이 작업은 이 요구사항에서 비롯되고, 이 요구사항은 승인된 의도에서 나옵니다.

이러한 연계 관계가 있어야 자율적 배포 과정을 감사할 수 있습니다. 이가 없으면 작동하는 코드는 있지만 왜 해당 코드가 요청한 대로인지에 대한 설명은 없게 됩니다.

이것이 계획과 어떤 관련이 있을까요?#

SDLC 워크플로우와계획은 서로 다른 검토 단계입니다:

• SDLC 워크플로우는는을 승인하며무엇을만들지 결정하고, 이때는 아직 구체적인 접근 방안이 확정되지 않은 상태입니다.
• 계획은은을 승인하며방식으로코드가 작성되기 전에 구현할지를 결정합니다.

이 중 하나만 사용하거나 둘 다 사용하거나 아니면 아예 사용하지 않아도 됩니다. 둘 다 사용하는 것이 완성된 pull request에 대해 이견이 있을 때 다시 검토하는 것보다 비용이 더 저렴합니다.

관련 항목#

• 사양
• 작업이 어떻게 pull request로 변환되는가?
• 품질 게이트