증거를 바탕으로 릴리스 결정하기

결정을 정확히 명시하세요

파이프라인의 모든 검사가 통과했다는 것은 그 검사들에서 얻은 증거입니다. 릴리스 결정 전체를 설명하지는 않습니다. 담당자는 무엇이 어디에서 바뀌고 어떤 결과가 남는지 알아야 합니다.

가상의 고객 내보내기에서 수락된 커밋과 그 커밋으로 만든 아티팩트를 식별하세요. 대상 환경을 명시하세요. 관련 테스트, 검토, 승인된 예외를 연결하세요. 애플리케이션에 수반되는 데이터나 인프라 변경도 포함하세요.

NIST의 SSDF는 안전한 개발 관행을 제공하며 SLSA 생성 이력은 아티팩트가 만들어진 방법을 설명하는 데 도움이 됩니다. 어느 것도 이번 릴리스가 이 서비스에 적합한지 결정할 필요를 없애지는 않습니다. NIST SSDF, SLSA 생성 이력.

머지는 소스 변경을 브랜치에 반영합니다. 배포는 아티팩트를 환경에 배치합니다. 기능 공개는 사용자가 해당 동작을 이용할 수 있게 합니다. 동시에 일어날 수 있지만 반드시 같은 사건은 아닙니다.

서비스는 비활성 기능을 배포하고 나중에 공개할 수 있습니다. 데이터베이스 마이그레이션은 눈에 보이는 기능이 나타나기 전에 프로덕션에 영향을 줄 수 있습니다. PR 머지가 모든 결과를 설명한다고 가정하지 말고 실제 순서를 정하세요.

내보내기 기능에서는 기능 플래그가 초기 공개 범위를 제한할 수 있습니다. 하지만 새 엔드포인트를 자동으로 보호하거나 스키마 마이그레이션을 되돌리지는 않습니다. 결과가 발생하는 지점에서 통제를 검증하세요.

다른 책임자가 살펴볼 수 있는 기록을 사용하세요.

주장을 구체적으로 유지하세요. ‘테스트 통과’보다 검사 범위가 명확히 설명된 릴리스 커밋의 결과 링크가 더 나은 증거입니다. ‘롤백 가능’보다 한계가 명시된 테스트 완료 절차가 더 나은 증거입니다.

실행 전에 릴리스 조건을 정하세요. 가상의 내보내기에서는 다른 조직 접근이 성공하거나, 아티팩트가 수락된 다이제스트와 다르거나, 복구할 수 없으면 중지하세요. 이는 조건의 예시이지 모든 상황에 적용되는 체크리스트가 아닙니다.

배포 후에는 사용자에게 중요한 신호를 살펴보세요. 오류 동작과 응답 시간을 서비스가 수락한 목표와 비교하세요. 프로세스가 정상이라고 사용자 작업 흐름도 작동한다는 증거는 아닙니다.

조건을 충족하지 못하면 합의한 대응을 실행하세요. 기능 공개를 중단하거나 호환되는 코드를 롤백하거나 데이터를 복구할 수 있습니다. 더 큰 실패를 만들지 않으면서 현재 실패를 해결하는 조치를 선택하세요.

실제로 배포한 아티팩트와 결과를 기록하세요. 실행이 계획과 다르면 그 차이를 드러내세요. 사고와 예상하지 못한 작업을 다음 릴리스 설계에 반영하세요.

자동화된 소프트웨어 제공 시스템은 이 기록을 더 쉽게 살펴볼 수 있게 해야 합니다. 검토자가 서로 떨어진 대화, 로그, 스크린샷을 모아 릴리스를 재구성해야 해서는 안 됩니다. 명확한 증거가 있으면 팀은 책임 있는 결정을 유지하면서 일상 작업을 자동화할 수 있습니다.