배포 전 준비 상태 평가

변경 요청이 생성되기 전에 파이프라인은 배포 준비 상태를 계산하고 DEPLOYMENT_READY 플래그를 true 또는 false 로 설정합니다. 이 플래그는 CI 및 CD 단계에서 수집된 증거에서 파생됩니다. 증거 검사에서 배포된 아티팩트 세트와 관련된 편차, 누락 또는 실패한 검사, 스캔 또는 테스트가 표시되면 DEPLOYMENT_READY 이 false 으로 설정됩니다.

변경 요청은 대상 지점에 마지막으로 병합된 프로모션 PR에서 소싱한 다음 필드를 사용하여 준비됩니다:

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

변경 요청 생성

준비된 변경 요청은 DEPLOYMENT_READY 에 따라 두 가지 초기 상태 중 하나로 제출됩니다:

또한 변경 관리 시스템은 구현으로 인해 가동 중단 시간이 발생하지 않고(가동 중단 시간이 0이고 DEPLOYMENT_READY 이 true 이며 배포 위험이 허용 가능한 한도 내에 있는 경우 변경 요청을 자동으로 승인합니다.

변경에 계획된 가동 중단이 필요한 경우 변경 요청을 수동으로 작성하고 승인을 위해 전송해야 합니다. 승인된 후 변경 요청 ID를 제공하여 배치를 시작할 수 있습니다. 파이프라인은 승인 상태를 확인한 다음 배포를 실행합니다. 자세한 정보는 수동으로 변경 요청 승인 을 참조하십시오.

배포 전 첨부 파일

변경 요청이 생성된 직후 파이프라인은 다음 아티팩트를 CR 레코드에 첨부합니다:

• 배포 BOM- 배포에 포함된 모든 구성 요소를 나열합니다
• 델타 요약- 배포에 참여하는 모든 구성 요소의 증거 태세
• 증거 확인 구성 파일- 파이프라인에 필요한 증거 확인 기반 게이팅이 구성된 경우에만 첨부됩니다
• SCC 프로필- 보안 및 규정 준수 구성이 구성된 경우에만 첨부됩니다

승인 게이트

변경 요청이 승인되지 않음으로 생성된 경우 미승인 상태가 되어 사람의 검토를 위해 전송됩니다. 승인을 받을 때까지 배포가 이루어지지 않습니다.

파이프라인 로그에서 생성된 변경 요청 ID를 확인한 후 승인을 기다렸다가, 동일한 변경 요청 ID를 사용하여 배포를 다시 시작할 수 있습니다. 파이프라인은 승인 상태를 확인하고 배포를 계속 진행합니다.

배포 및 승인 테스트

CR이 구현 상태이면 파이프라인이 실행됩니다:

• CD 배포- 대상 환경으로 코드 승격
• 수락 테스트- 배포 결과를 검증합니다

이 두 단계는 사용자 주도의 실행 단계입니다.

배포 후 CR 종료

배포 및 수락 테스트가 통과되면 파이프라인은 종료 아티팩트를 첨부하고 변경 요청을 종료합니다:

• 클로징 요약- 대상 커밋 레벨의 모든 인벤토리 항목에 대한 증거를 요약한 것입니다.
• 인벤토리의 모든 구성 요소에 대한 배포 후 소프트웨어 자재 명세서인 SBOM을 통합했습니다.

그런 다음 CR은 마감 시간에 DEPLOYMENT_READY 을 기준으로 close_category 으로 마감됩니다:

변경 유형

변경 요청 관리는 긴급 변경과 일반 변경, 두 가지 유형을 지원합니다.

현재 변경 사항이 긴급 변경 사항인 경우, 프로모션 풀 리퀘스트에 ‘ emergency ’ 라벨을 추가해 주세요.

CI 파이프라인 쪽에는 비상 흐름이 없습니다. 그러나 CI 파이프라인/트리거 속성 skip-inventory-update-on-failure 을 빈 값 또는 0 으로 설정하면 CI 파이프라인 실행에서 문제가 감지되더라도 인벤토리 리포지토리를 업데이트할 수 있습니다. 이 업데이트된 인벤토리로 긴급 변경을 활성화할 수 있습니다.

복구 경로 선택

경로 1: 전용 롤백 리스너를 사용한 전체 롤백

마지막으로 알려진 양호한 구성, 즉 안정적으로 확인된 이전에 배포된 상태가 존재하는 경우 서비스를 복원하는 가장 빠른 경로는 전체 롤백입니다. 이 시나리오를 위해 특별히 제작된 전용 롤백 리스너를 사용하며 새로운 빌드나 프로모션이 필요하지 않습니다.

단계별 지침과 구성할 매개변수는 전용 롤백 리스너를 사용한 전체 롤백을 참조하세요.

경로 2: 긴급 변경으로 수정 추진

실행 가능한 롤백 대상이 없거나 조사에서 이미 패치가 생성된 경우 긴급 변경 사항으로 수정 사항을 배포할 수 있습니다. 이 경로는 표준 증거 게이팅 로직을 단락시켜 파이프라인을 통해 변경을 즉시 구현하고 변경 요청은 인시던트가 해결된 후 소급 검토 및 승인을 받도록 허용합니다.

이 경로를 사용한다는 것은 프로덕션에 배포된 코드에 여전히 해결되지 않은 취약점이나 증거 공백이 있을 수 있음을 인정하는 것입니다. 서비스 복구가 최우선 순위로 처리되며 미해결된 규정 준수 항목은 인시던트가 종료된 후에 해결해야 합니다.

이 두 경로는 상호 배타적이지 않습니다. 실제로 팀은 먼저 전체 롤백을 시작하여 서비스를 즉시 복구한 다음 패치가 준비되고 검증되면 픽스 포워드로 후속 조치를 취할 수 있습니다. 순서는 상황에 따라 운영자의 판단에 맡겨집니다.

수정 전달 절차

CIE 중에 긴급 변경 사항으로 수정 사항을 배포하려면 다음 단계를 따르세요:

1. 영향을 받는 컴포넌트를 다시 빌드합니다. CI 파이프라인을 실행하여 수정 사항이 포함된 새 아티팩트 버전을 빌드합니다. 인시던트 조건으로 인해 CI 증거 확인이 실패하는 경우, 파이프라인 또는 트리거 속성 skip-inventory-update-on-failure 을 빈 값으로 설정하거나 0 을 설정하여 실패에도 불구하고 인벤토리를 업데이트할 수 있도록 하여 긴급 변경을 진행할 수 있도록 하세요.

2. 환경을 통해 수정 사항을 홍보하세요. 가장 낮은 환경부터 승격 풀 리퀘스트를 생성하고 프로덕션으로 승격하세요. 시간이 허락한다면 더 홍보하기 전에 각 단계에서 수정 사항을 확인합니다. 상황이 심각한 경우 프로덕션으로 바로 승격하고 서비스가 복구된 후 하위 환경을 조정하세요.

3. 긴급 라벨을 부착합니다. 프로덕션을 대상으로 하는 프로모션 풀 리퀘스트에서 emergency 레이블을 추가합니다. 이는 파이프라인에 표준 증거 게이팅을 우회해야 하며 변경 사항을 긴급 배포로 처리해야 한다는 신호를 보냅니다.

4. 프로덕션에 배포합니다. CD 파이프라인을 실행합니다. 파이프라인은 긴급 라벨을 감지하고 승인 대기 과정을 건너뛰고 즉시 배포 및 승인 테스트를 진행합니다. 변경 요청은 긴급 상황에서 배포되었음을 반영하여 close_category = successful with issues 로 생성 및 종료됩니다.

5. 낮은 환경을 조정합니다. 프로덕션 인시던트가 해결된 후에는 동일한 긴급 수정 아티팩트를 하위 환경(스테이징, 프리 프로덕션 등)에 배포하여 모든 환경이 프로덕션과 일관된 상태를 유지하도록 합니다. 프로덕션 환경으로 승격하기 전에 하위 환경을 검증했다면 모든 티어에 동일한 아티팩트 버전이 적용되었는지 확인하세요.

CIE 이후 의무 사항

긴급 배포에는 인시던트가 종료된 후 해결해야 하는 규정 준수 의무가 발생합니다:

• 변경 요청은 해당 승인자가 소급하여 검토하고 승인해야 합니다.
• 긴급 상황에서 해결되지 않은 취약점, 불완전한 검사, 검사 실패 등 증거의 공백이 발견되면 이를 해결하고 표준 조건에서 파이프라인을 다시 실행해야 합니다.
• 근본 원인 분석(RCA)을 수행하고 문서화해야 합니다.

파이프라인에 첨부된 델타 요약, 마감 요약 및 병합된 SBOM을 포함한 변경 요청 기록은 CIE 이후 검토를 위한 기본 감사 추적 역할을 합니다.

비상 흐름 호출하기

비상 흐름은 사용자가 시작합니다:

1. 사용자는 프로모션 풀 리퀘스트에 emergency 레이블을 적용하여 파이프라인을 실행합니다.
2. 파이프라인은 긴급 지정을 감지하고 표준 승인을 기다릴 필요 없이 즉시 배포 및 승인 테스트를 진행합니다.
3. CR은 successful with issues 로 마감되며 마감 메모와 함께 닫힙니다.

현재 변경 사항이 긴급 변경 사항인 경우, 파이프라인을 실행하기 전에 프로모션 풀 리퀘스트에 emergency 레이블을 추가하십시오.

긴급 배포 후

비상 흐름이 배포 및 테스트를 완료하면 배포 후 단계에서 표준 흐름에 다시 합류합니다:

• 결산 요약 및 병합된 SBOM이 CR에 첨부됩니다.
• CR은 표준 흐름과 동일한 DEPLOYMENT_READY 기반 close_category 로직에 따라 닫힙니다.

CR 유형이 emergency 인 경우 배포 후 변경 요청을 소급하여 검토하고 승인해야 합니다.

트리거 조건

인라인 롤백 흐름은 배포 또는 승인 테스트가 통과하지 못할 때 입력됩니다. 그런 다음 파이프라인은 인라인 롤백이 활성화되어 있는지 여부를 평가합니다:

• 인라인 롤백이 활성화되지 않았습니다: CR이 close_category = unsuccessful 로 열려 있고 파이프라인이 종료됩니다. 자동 복구가 시도되지 않습니다.
• 롤백이 활성화되었습니다: 롤백 스크립트가 실행되어 대상 환경을 되돌리고 롤백 아티팩트가 수집되어 CR에 첨부됩니다.

인라인 롤백 실행

인라인 롤백이 활성화되면 파이프라인이 활성화됩니다:

1. CD 파이프라인에서 배포 또는 수락 테스트가 실패한 경우 인라인 롤백 스크립트를 실행합니다.
2. 다음 아티팩트를 수집합니다:
   • 롤백 로그- 롤백 스크립트 실행의 결과물
   • 결산 요약- 롤백 결과를 반영합니다
   • 병합된 SBOM- 롤백 후 소프트웨어 자재 명세서
3. 세 가지 아티팩트를 모두 열린 CR 레코드에 첨부합니다.

롤백 후 CR 종료

인라인 롤백 및 아티팩트 첨부 후 CR은 close_category = unsuccessful 로 열려 있습니다. 이는 배포가 시도되었으나 실패하여 자동으로 되돌렸음을 변경 관리팀에 알리는 신호입니다.

close_category = unsuccessful 의 CR은 배포를 되돌릴 때 예상되는 올바른 결과이며 프로세스 실패를 나타내는 것이 아닙니다. 운영팀은 첨부된 롤백 로그를 사용하여 근본 원인을 조사해야 합니다.

사전 승인된 변경 요청으로 파이프라인 실행하기

배포 시 사전 승인된 변경 요청(CR)을 사용할 수 있습니다. 두 가지 시나리오가 가능합니다:

CD 파이프라인이 이전 CD 파이프라인 실행에서 생성된 CR을 인식하면 배포 경로를 빠르게 지정합니다:

• CR 증거에서 미리 계산된 델타와 증거 요약 재사용.
• 동료 검토 및 서명 검증 단계를 생략합니다.
• 사전 계산된 델타 배포 중.

CD 파이프라인이 이전 CD 파이프라인 실행에 의해 생성된 CR인지 여부를 확인할 수 없는 경우이거나 제공된 CR이 현재 실행 중인 배포 대상과 일치하지 않습니다:

• 사전 계산된 델타 또는 증거 요약은 재사용하지 않습니다.
• 동료 검토나 아티팩트 서명 확인을 건너뛰지 않습니다.
• 델타와 요약을 처음부터 다시 계산합니다.
• 이미 CR이 제공되었으므로 새 CR을 생성하지 않습니다.

실패한 배포에 대해 파이프라인 다시 실행하기

자동화된 변경 관리를 사용하지 않으려면, 대신 미리 작성하고 승인받은 변경 요청서를 제출할 수 있습니다. 다음 시나리오에서 실패한 배치를 다시 실행하십시오.

• 가장 최근에 자동으로 생성된 변경 요청은 배포 준비가 되지 않았으며 자동 승인되지 않았습니다. 승인을 받았으며 동일한 변경 요청을 사용하여 배포를 다시 시작해야 합니다.
• 배치에 가동 중단이 필요합니다. 귀하가 변경 요청을 생성했고, 해당 요청은 승인되었으며, 귀하는 조직의 변경 관리 정책을 준수했습니다.
• 코드나 구성이 변경되지 않았습니다. 변경 요청을 만들고, 변경 내용을 설명하고, 승인을 받은 후 승인된 변경 요청을 사용하여 배포를 시작했습니다.

변경 요청(CR)은 CD 파이프라인이 완료된 후에도 계속 열려 있습니다.

사전 승인된 변경 요청을 사용하고 change-request-id 속성에 해당 변경 요청 ID를 입력하면 DevSecOps 참조 지속적 배포 파이프라인을 시작할 수 있습니다.

change-request-id 속성이 설정된 경우, 파이프라인은 해당 변경 요청에 대한 데이터 수집을 건너뛰고 승인 상태 확인 단계로 바로 진행합니다. 'change-request-id'가 기본적으로 notAvailable 로 설정되어 있는 경우, 파이프라인에서 변경 요청이 자동으로 생성됩니다.