기본 동작 (강제 재배포 없이)

설정되지 않았거나 force-redeploy 로 설정된 false 경우, 파이프라인은 대상 환경의 인벤토리 저장소에서 새로운 변경 사항이 감지될 때만 배포됩니다.

1. CD 파이프라인이 시작되고 현재 커밋에 파이프라인 실행 ID를 태그합니다.

2. 파이프라인은 해당 태그에서 대응하는 환경 브랜치의 내용을 읽습니다.

3. 파이프라인은 현재 커밋과 <target-environment>_latest 태그와 연결된 커밋 사이의 배포 델타를 계산합니다.

4. 파이프라인은 델타를 평가합니다:

   • 델타가 비어 있으면 파이프라인이 중지되고 배포가 수행되지 않습니다.
   • 델타에 변경 사항이 포함된 경우 파이프라인이 계속 진행됩니다.

5. 파이프라인은 델타에서 식별된 변경 사항을 배포합니다.

6. 배포가 성공적으로 완료된 후, 파이프라인은 새 커밋에 <target-environment>_latest 태그를 추가합니다.

강제 행동 (강제 재배치 포함)

가 로 force-redeploy``true 설정되면, 파이프라인은 델타 검증을 우회하고 감지된 변경 사항과 관계없이 전체 인벤토리를 재배포합니다. 이 접근 방식은 전체 애플리케이션 상태가 배포 대상에 재적용되도록 보장합니다.

1. CD 파이프라인이 시작되고 현재 커밋에 파이프라인 실행 ID를 태그합니다.
2. 파이프라인은 해당 태그에서 대응하는 환경 브랜치의 내용을 읽습니다.
3. 파이프라인은 배포 델타를 계산하며, 이 시나리오에서는 일반적으로 비어 있습니다.
4. 해당 force-redeploy=true 설정은 파이프라인이 델타 검사를 건너뛰고 진행하도록 합니다.
5. 파이프라인은 브랜치에서 애플리케이션 상태 전체를 재배포합니다.
6. 성공적인 재배포 후, 파이프라인은 방금 배포한 커밋에 <target-environment>_latest 태그를 부착합니다.

롤백 파이프라인 개요

이 파이프라인을 사용하면 특정 ServiceNow 변경 요청 ID(예: CHG-12345)를 대상으로 지정하여 이전의 정상으로 확인된 구성으로 롤백할 수 있습니다.

이 변경 요청 ID는 성공적인 배포에 대한 고유한 북마크 역할을 하며 롤백 파이프라인에 필수 입력값입니다.

이전 배포의 변경 요청 ID는 두 가지 방법으로 확인할 수 있습니다:

• ServiceNow: 복원하려는 배포에 대한 변경 요청을 찾습니다.
• 인벤토리 저장소: 인벤토리 상태가 소스 제어에서 관리되므로, 각 배포는 커밋으로 고유하게 식별됩니다. 원하는 커밋으로 되돌리려면 해당 커밋과 연관된 CHG-*** 태그를 찾아 식별할 수 있습니다.

롤백 파이프라인은 다음 단계를 포함합니다:

• prod-rollback-start
• prod-setup
• prod-rollback-change-request
• prod-deployment
• prod-acceptance-tests
• prod-rollback-finish

파이프라인 실행은 환경 rollback-change-request-id 속성의 정보를 사용하여 새로운 변경 요청을 생성합니다.

규정 준수를 유지하기 위해 파이프라인은 이전 배포와 연결된 이슈를 재개합니다. 이러한 이슈들은 새로운 변경 요청에 첨부되었으며, 원래 마감일은 변경되지 않습니다. 성공적인 롤백은 인벤토리 내 _latest 태그를 이전 커밋으로 이동시킵니다.

롤백 파이프라인 생성

사용하여 마지막으로 알려진 정상 cd-rollback-listener 버전으로 롤백을 실행합니다.

1. CD 파이프라인으로 이동하십시오.
2. 수동 트리거를 추가하거나 수동 CD 트리거 를 복제하십시오.
3. 트리거를 편집하고 리스너를 로 설정하십시오 cd-rollback-listener.
4. 저장을 선택하십시오.
5. 필요한 각 지역 및 대상 환경 조합에 대해 별도의 트리거를 생성하십시오.

롤백 파이프라인 트리거

롤백 파이프라인 실행은 다음 환경 속성을 사용합니다:

다음 기준이 충족되지 않는 한 파이프라인은 종료됩니다:

• rollback-change-request-id 동일한 리전 및 대상 환경에 대한 완료된 배포의 ID여야 합니다.
• 해당 배포는 rollback-limit으로 rollback-change-request-id 지정된 배포 횟수보다 오래되어서는 안 됩니다.

Tekton 환경 PIPELINE_NAME 속성은 실행이 배포인지 롤백인지 여부를 결정합니다.

• cd-rollback-pipeline 롤백의 기본값.
• cd-pipeline 배포의 기본값.

이 속성을 사용하여 분기 논리를 사용자 정의할 수 있습니다.

롤백 사용 개요 GitOps

지속적 배포 파이프라인을 사용하여 변경 사항을 특정 시점으로 되돌리는 작업을 Git 통해 이전 버전의 commit-id 인벤토리를 대상 환경에 배포하십시오.

인벤토리 저장소에서 커밋을 직접 롤백하고 변경 요청 ServiceNow ID로 롤백 파이프라인을 트리거하지 않기 때문에, 이 프로세스는 이전 규정 준수 이슈를 자동으로 재개하거나 해당 마감일을 관리하지 않습니다.

트리거되면 CD 파이프라인은 재배포를 위해 다음 단계를 완료합니다:

• 파이프라인이 시작되고 현재 커밋(되돌리기 커밋)에 파이프라인 실행 ID를 태그합니다.
• 파이프라인은 해당 태그에서 대응하는 환경 브랜치의 내용을 읽습니다.
• 파이프라인은 현재 커밋과 <target-environment>_latest 태그와 연결된 커밋 사이의 배포 델타를 계산합니다.
• 성공적인 배포 후, 태그는 <target-environment>_latest 새로운 (되돌려진) 커밋으로 이동됩니다.

롤백 프로모션 풀 리퀘스트 생성

1. 인벤토리에서 롤백하려는 배포 버전의 commit-id 식별자를 확인하십시오.
2. 저장소 상태를 해당 커밋으로 되돌립니다.
3. 되돌린 상태를 적용하기 위해 풀 리퀘스트를 생성하십시오.

다음 예시는 명령어를 git 사용하여 이 시나리오를 보여줍니다.

1. 커밋 및 태그 목록을 표시하여 마지막으로 알려진 정상 상태의 커밋 ID를 찾습니다(예: refs/tags/8)

   # /c/usr/devsecops/compliance-inventory (master)
   $ git show-ref --tags
   ...
   83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8 refs/tags/8
   ...
   1914a125e76aa97c497f4bd2c2f455b58cf079b8 refs/tags/prod_latest
   

2. 현재 상태 (refs/tags/prod_latest)와 목표 상태 (refs/tags/8) 사이의 모든 커밋을 나열하십시오.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   67cc8babdff3e09c1f0e632f897798c1b5424f38
   6fab5ce3d60590cd858206424ecfd7d3a8c9ceb4
   ...
   

3. 인벤토리 상태를 대상 커밋(refs/tags/8)으로 되돌립니다.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git revert -n $(git rev-list --no-merges HEAD...83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8)
   

4. 새 상태를 커밋합니다.

   # /c/usr/devsecops/compliance-inventory (master|REVERTING)
   $ git commit -m "revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8"
   [master af82538] revert master to 83f7a87ee59185eaeac554bd3abeebfd2c1b4ad8
   

5. 업데이트를 마스터 브랜치로 푸시하세요.

   # /c/usr/devsecops/compliance-inventory (master)
   $ git push --set-upstream origin master
   ...
   To [https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git](https://us-south.git.cloud.ibm.com/jaunin.b/compliance-inventory.git)
     67cc8ba..af82538  master -> master
   ...
   

지속적 배포 파이프라인을 트리거합니다

1. 롤백 승진 변경 사항에 대한 풀 리퀘스트를 생성하십시오.

2. 풀 리퀘스트를 검토하고 병합합니다.

3. CD 툴체인에서 수동 CD 파이프라인 실행을 트리거하십시오.

인라인 롤백 개요

이 모드는 동일한 파이프라인 실행 컨텍스트 내에서 현재 배포를 롤백합니다. 배포 또는 인수 테스트 단계에서 오류나 장애가 발생하여 배포 시도가 실패로 표시될 때 필요합니다.

환경 rollback-enabled 속성이 로 설정되어 1 있고 배포 또는 승인 테스트 단계에서 오류가 발생하면 인라인 롤백이 자동으로 실행됩니다.

롤백이 트리거되면 CD 파이프라인은 .pipeline-config.yaml 파일에서 rollback 에 대해 정의된 세그먼트를 실행합니다. 파일에 rollback 세그먼트가 정의되지 않은 경우 기본 구현이 실행되며 롤백 스크립트를 제공하도록 요청합니다.

예시 롤백 스크립트: .pipeline-config.yaml

rollback:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.74
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/deploy_setup.sh
    source $WORKSPACE/$PIPELINE_CONFIG_REPO_PATH/scripts/rollback.sh

인라인 롤백 중에 설정된 속성

• rollback-status 롤백 단계의 상태를 나타냅니다. 가능한 값: [notRun, success, failure]
• rollback-exit-code 롤백 단계의 종료 코드. 롤백이 실행되지 않은 경우 이 값은 비어 있습니다.
• default-rollback-executed 기본 구현(스크립트 입력을 요청하는)이 실행된 경우 true true로 설정합니다. 이 값은 기본적으로 비어 있습니다.
• pipeline-execution-status 전체 파이프라인 실행 상태를 나타냅니다. 가능한 값: [successful_deployment, failed_deployment_failed_rollback, failed_deployment_successful_rollback]