Rollback Strategy

Rollback tốt giảm thời gian khôi phục nhưng không được biến Jenkins thành nơi tự ý sửa production. Jenkins chỉ điều phối gate, approval và evidence. Artifact repository, nền tảng deploy, database, feature-flag service và hệ thống quan sát vẫn phải có policy, identity và audit riêng.

Mục lụcCopy Anchor Link

• Mục tiêu và nguyên tắc
  • Rollback và forward-fix
  • Tiêu chí quyết định
• Artifact bất biến và release metadata
  • Known-good không chỉ là build xanh
  • Evidence tối thiểu
• Giảm blast radius trước khi rollback
  • Feature flag
  • Traffic và cấu hình
• Database tương thích khi quay lui
  • Expand, migrate, contract
  • Khi binary rollback không an toàn
• Runbook rollback
  • Điều kiện vào và phân quyền
  • Các bước thực thi
  • 1. Dừng mở rộng phạm vi
  • 2. Quan sát state thực tế
  • 3. Chọn và xác minh candidate
  • 4. Phê duyệt và thực hiện action hẹp
  • 5. Xác minh sau action
  • 6. Ghi evidence và theo dõi
  • Tiêu chí hoàn tất
• Jenkins Pipeline: gate và approval
  • Hợp đồng script và trust boundary
  • Jenkinsfile tham khảo
  • Đọc outcome đúng cách
• Rollback drill và runbook rehearsal
• Lab không-production an toàn
  • Điều kiện và Jenkinsfile lab
  • Kết quả mong đợi
• Troubleshooting
• Checklist xác minh
• Nguồn chính thức
• Đọc tiếp

Mục tiêu và nguyên tắcCopy Anchor Link

Sau bài này, bạn có thể chọn rollback, forward-fix hoặc giữ nguyên trạng thái dựa trên evidence; quay về đúng artifact bất biến; tắt một capability bằng feature flag theo policy; và tránh đưa binary cũ lên schema mới không tương thích. Mục tiêu là khôi phục dịch vụ có kiểm soát, không phải làm build dashboard trở lại màu xanh.

Rollback và forward-fixCopy Anchor Link

Rollback triển khai lại một artifact known-good đã tồn tại và đã được xác minh. Ví dụ, release hiện tại chạy catalog-api@sha256:new; rollback phải yêu cầu chính xác catalog-api@sha256:known-good, không checkout một commit cũ rồi build lại.

Forward-fix tạo release mới để sửa lỗi. Đây thường là lựa chọn an toàn hơn khi release mới đã ghi dữ liệu theo dạng mà binary cũ không hiểu, hoặc migration đã thay đổi schema theo chiều không đảo được. Giữ nguyên trạng thái cũng có thể đúng khi tín hiệu chưa đủ tin cậy và việc thay đổi tiếp sẽ tăng blast radius.

Tiêu chí quyết địnhCopy Anchor Link

Không dùng một ngưỡng chung cho mọi service. Owner sản phẩm, on-call, database owner và release policy quyết định ngưỡng cụ thể. Tuy vậy, quyết định cần trả lời các câu hỏi sau trước khi Jenkins thực hiện action:

1. Tác động có thật không? Đối chiếu error rate, latency, saturation, synthetic check, business signal và thời điểm release. Một alert đơn lẻ có thể là lỗi quan sát; nhiều tín hiệu cùng hướng mạnh hơn.
2. State thực tế là gì? Đọc digest/revision đang chạy, rollout state, traffic split, config/flag state và migration version. Console Jenkins không phải source of truth duy nhất.
3. Rollback candidate có còn dùng được không? Xác minh digest, checksum/chữ ký theo policy, retention registry và health evidence của lần chạy tốt trước đó.
4. Contract có tương thích không? Kiểm API consumer, schema/database, queue message, cache format và cấu hình. Nếu chưa biết, không ép binary cũ chạy.
5. Ai phê duyệt và ai thực thi? Production cần owner/approver theo change policy. Người sửa Jenkinsfile hay publish artifact không nên là approver duy nhất cho chính thay đổi đó.

Artifact bất biến và release metadataCopy Anchor Link

Known-good không chỉ là build xanhCopy Anchor Link

Artifact bất biến là package, binary hoặc OCI image không đổi bytes sau publish. Với image, dùng reference repository@sha256:...; tag chỉ phù hợp để con người tìm kiếm vì tag có thể bị ghi đè. Release rollback phải dùng cùng loại identity bất biến với release ban đầu.

Known-good không chỉ là build từng thành công. Nó là artifact có provenance phù hợp, đã qua gate của policy, từng chạy khỏe trong context tương thích và còn có thể lấy/verify. Một digest từng pass staging không mặc nhiên là production rollback candidate nếu production config, migration hoặc traffic model đã thay đổi.

Evidence tối thiểuCopy Anchor Link

Release manifest không chứa secret. Nó là record đã review, có thể ký/xác minh theo policy, nối artifact với source, gate và action. Tên hệ thống, URL nội bộ hoặc token không cần có trong manifest để nó có giá trị.

Jenkins fingerprint giúp nối file qua build, nhưng không thay SHA-256, chữ ký hoặc artifact repository có immutability. Build retention Jenkins cũng không thay retention của registry/audit store. Thử đọc lại manifest và tải candidate theo lịch để phát hiện retention làm mất đường rollback trước sự cố thật.

Giảm blast radius trước khi rollbackCopy Anchor Link

Rollback artifact có thể mất vài phút hoặc không an toàn. Trong thời gian đó, một control tách biệt có thể giảm tác động. Các control này không thay artifact rollback và mỗi control cần owner, audit, quyền tối thiểu cùng một runbook riêng.

Feature flagCopy Anchor Link

Feature flag là configuration có kiểm soát bật/tắt một capability tại runtime. Ví dụ, release mới có endpoint export; flag export_v2 mặc định tắt đến khi telemetry cho thấy nó ổn định. Khi endpoint gây lỗi, tắt flag có thể giảm traffic vào capability mà không thay toàn bộ binary.

Một flag không rollback migration, message đã publish hay side effect đã thực hiện. Trước khi toggle, ghi current state, desired state, scope tenant/traffic, reason và owner. Sau khi toggle, kiểm telemetry trong cửa sổ policy; không kết luận thành công chỉ vì API flag trả 200.

Traffic và cấu hìnhCopy Anchor Link

Canary, blue/green hoặc traffic split có thể cô lập release mới nếu platform hỗ trợ. Chúng cần ownership của ingress/service mesh/load balancer và metric theo revision. Jenkins không nên sửa traffic route trực tiếp nếu GitOps controller hay platform controller là source of truth; hai reconciler cùng ghi một resource sẽ tạo race.

Cấu hình cũng là một release input. Nếu rollback binary mà config mới không tương thích, service vẫn có thể fail. Pin config revision/reference trong release metadata; đánh giá config rollback như change riêng. Không dùng config edit khẩn cấp vô danh để "sửa nhanh", rồi mất khả năng tái hiện state.

Database tương thích khi quay luiCopy Anchor Link

Expand, migrate, contractCopy Anchor Link

Schema và data thường sống lâu hơn một binary release, vì vậy database cần thay đổi theo nhiều release. Mẫu expand, migrate, contract giữ compatibility trong giai đoạn chuyển tiếp:

1. Expand: thêm cột, bảng, index hoặc API mới theo cách không phá consumer cũ. Ví dụ thêm display_name nullable, không xóa name.
2. Migrate: release application có thể đọc cả name và display_name; backfill chạy có batch, rate limit, checkpoint và quan sát. Chỉ chuyển writer/reader sau khi evidence cho thấy dữ liệu phù hợp.
3. Contract: chỉ sau khi mọi consumer cũ đã bị loại và rollback window kết thúc, xóa cột/contract cũ trong release tách biệt. Đây không phải action tự động trong post { failure }.

Khi binary rollback không an toànCopy Anchor Link

Dừng rollback artifact và chuyển sang decision owner khi có một trong các dấu hiệu sau: migration destructive đã chạy; dữ liệu mới không còn parse được bởi version cũ; event schema không tương thích đã được publish; config/secret contract đã đổi; hoặc backup/restore chưa được xác minh. Lựa chọn có thể là forward-fix, feature flag, read-only/degraded mode hoặc restore dữ liệu theo kế hoạch được phê duyệt.

Runbook rollbackCopy Anchor Link

Điều kiện vào và phân quyềnCopy Anchor Link

Kích hoạt runbook khi health/telemetry đã xác nhận tác động theo ngưỡng policy, hoặc khi owner quyết định rủi ro của release cao hơn rủi ro quay lui. Chỉ dùng production lane từ protected branch/job; pull request, fork và agent không tin cậy không được nhận credential publish, deploy hoặc flag production.

Trước action, release commander hoặc owner ghi incident/change ID, target logical, reason, current digest, rollback digest, migration/flag assessment và người ra quyết định. Approval Jenkins là evidence hữu ích nhưng không thay Jenkins authorization, IAM của deployment platform, RBAC database hoặc change-management policy.

Các bước thực thiCopy Anchor Link

1. Dừng mở rộng phạm viCopy Anchor Link

Dừng promotion sang môi trường kế tiếp. Nếu policy cho phép, pause canary/auto-sync hoặc tắt capability bằng flag đã được rehearsed. Ghi state trước action; không xóa workload, đổi tag hay chạy cleanup rộng để "bắt đầu lại".

2. Quan sát state thực tếCopy Anchor Link

Dùng API/platform command chỉ đọc theo target đã allowlist để thu current digest/revision, rollout, traffic split, feature flag, migration version và tín hiệu health. Nếu deploy timeout hoặc state mâu thuẫn, giữ trạng thái là unknown và escalation thay vì gửi lệnh lần hai.

3. Chọn và xác minh candidateCopy Anchor Link

Lấy rollback candidate từ release record, không từ tên tag. Verify manifest, digest/checksum, provenance/chữ ký theo policy, availability ở repository, health evidence trước đó và compatibility database/config. Nếu bất kỳ điều kiện nào không đạt, dừng và chọn forward-fix hoặc data recovery theo owner.

4. Phê duyệt và thực hiện action hẹpCopy Anchor Link

Đưa current/candidate digest, target logical, impact, change/incident ID và assessment migration vào approval. Deployer identity chỉ được gọi API cho workload/môi trường allowlist. Giữ lock hẹp quanh deploy và verification để một release khác không ghi đè kết quả.

5. Xác minh sau actionCopy Anchor Link

Xác nhận target thực sự chạy candidate digest, rollout hoàn tất, smoke check pass và telemetry ổn định trong cửa sổ policy. Kiểm tra flag/traffic/config đã ở state mong muốn. Rollback chỉ hoàn tất sau bước này, không phải khi deploy command trả exit code 0.

6. Ghi evidence và theo dõiCopy Anchor Link

Record action, identity, timestamp, before/after digest, health outcome và residual risk vào release/incident record đã redact. Giữ release lỗi là FAILURE, ABORTED hoặc outcome phù hợp; tạo work item cho nguyên nhân gốc, flag cleanup và contract migration.

Tiêu chí hoàn tấtCopy Anchor Link

Một rollback được coi là hoàn tất khi tất cả điều sau đúng: target state đọc lại khớp candidate immutable reference; health/smoke/telemetry đạt ngưỡng trong thời gian quan sát; dữ liệu và dependency không có dấu hiệu incompatibility; traffic/flag/config ở state được ghi nhận; và release record có decision owner cùng evidence. Nếu còn unknown, result đúng là rollback chưa được xác minh, không phải thành công giả.

Jenkins Pipeline: gate và approvalCopy Anchor Link

Hợp đồng script và trust boundaryCopy Anchor Link

Mẫu Pipeline dưới điều phối rollback nhưng không nhúng endpoint, credential hay lệnh platform-specific. Trước khi dùng, đội vận hành phải review/test các script nội bộ trong controller sandbox và xác minh plugin, agent label, credential scope, lock resource, IAM cùng target allowlist.

• ci/read-release-state chỉ đọc target logical và ghi state đã redact vào rollback/current-state.json.
• ci/verify-rollback-candidate kiểm manifest, digest, provenance và compatibility assessment; nó từ chối candidate thiếu evidence.
• ci/assess-rollback-safety kiểm migration/flag/config contract và trả non-zero khi cần forward-fix hoặc escalation.
• ci/deploy-known-good chỉ nhận target logical allowlist và digest đã verify; API đích phải idempotent hoặc có deployment ID để query state.
• ci/verify-rollback xác minh digest thực tế và health theo policy; ci/record-release-event ghi event đã redact ra audit store đã phê duyệt.

skipDefaultCheckout(true) cố ý chặn checkout ngầm. Mỗi stage chạy script bên dưới thực hiện checkout scm rõ ràng trước khi dùng ./ci/*; job phải cấu hình scm chỉ tới repository automation đã review, ref được bảo vệ và revision của build đã được Jenkins chọn, không nhận repository/ref từ parameter, PR hoặc fork. Checkout này là trust boundary: chỉ source đó được phép chạy trên trusted-release-linux; code không tin cậy không được dùng label này hoặc credential deploy.

Không bind credential ở cấp pipeline hoặc cho stage input. Agent trusted-release-linux phải tách khỏi agent chạy code PR. lock bên dưới cần Lockable Resources plugin; xác minh plugin và resource trên controller trước khi chuẩn hóa. Nếu chưa có, không giả định Jenkins core tạo distributed lock.

Jenkinsfile tham khảoCopy Anchor Link

pipeline {
  agent none

  options {
    skipDefaultCheckout(true)
    disableConcurrentBuilds()
    timeout(time: 45, unit: 'MINUTES')
  }

  parameters {
    choice(
      name: 'TARGET',
      choices: ['staging', 'production'],
      description: 'Logical environment; scripts enforce their own allowlist.'
    )
    string(
      name: 'INCIDENT_OR_CHANGE_ID',
      defaultValue: '',
      trim: true,
      description: 'Reference only; do not enter secrets or customer data.'
    )
  }

  stages {
    stage('Read actual state') {
      agent { label 'trusted-release-linux' }
      steps {
        // Explicit, trusted SCM checkout; implicit checkout is disabled globally.
        checkout scm
        sh '''#!/bin/sh
          set -eu
          test -n "$INCIDENT_OR_CHANGE_ID"
          mkdir -p rollback
          ./ci/read-release-state --environment "$TARGET" \
            --output rollback/current-state.json
          test -s rollback/current-state.json
        '''
        archiveArtifacts artifacts: 'rollback/current-state.json', fingerprint: true
        stash name: 'current-state', includes: 'rollback/current-state.json'
      }
    }

    stage('Verify rollback candidate') {
      agent { label 'trusted-release-linux' }
      steps {
        // Each agent gets only the job's trusted SCM revision before scripts run.
        checkout scm
        unstash 'current-state'
        sh '''#!/bin/sh
          set -eu
          ./ci/verify-rollback-candidate \
            --environment "$TARGET" \
            --current rollback/current-state.json \
            --output rollback/decision.json
          ./ci/assess-rollback-safety --decision rollback/decision.json
        '''
        archiveArtifacts artifacts: 'rollback/decision.json', fingerprint: true
        stash name: 'rollback-decision', includes: 'rollback/decision.json'
      }
    }

    stage('Approve production rollback') {
      when {
        beforeInput true
        expression { params.TARGET == 'production' }
      }
      options { timeout(time: 15, unit: 'MINUTES') }
      input {
        message 'Approve the recorded target, current digest, known-good digest, migration assessment, and incident/change reference?'
        ok 'Approve rollback'
        submitter 'release-managers'
        submitterParameter 'ROLLBACK_APPROVER'
      }
      agent { label 'trusted-release-linux' }
      steps {
        // The approval does not authorize an untrusted source checkout.
        checkout scm
        unstash 'rollback-decision'
        sh '''#!/bin/sh
          set -eu
          ./ci/record-release-event \
            --event rollback-approved \
            --environment "$TARGET" \
            --decision rollback/decision.json \
            --approver "$ROLLBACK_APPROVER" \
            --reference "$INCIDENT_OR_CHANGE_ID"
        '''
      }
    }

    stage('Deploy and verify known-good artifact') {
      agent { label 'trusted-release-linux' }
      steps {
        // Re-checkout because this stage may run in a separate agent workspace.
        checkout scm
        unstash 'rollback-decision'
        lock(resource: "rollback-${params.TARGET}-catalog-api") {
          sh '''#!/bin/sh
            set -eu
            ./ci/deploy-known-good --environment "$TARGET" \
              --decision rollback/decision.json
            ./ci/verify-rollback --environment "$TARGET" \
              --decision rollback/decision.json \
              --output rollback/verification.json
            ./ci/record-release-event \
              --event rollback-verified \
              --environment "$TARGET" \
              --decision rollback/decision.json \
              --verification rollback/verification.json \
              --reference "$INCIDENT_OR_CHANGE_ID"
          '''
        }
        archiveArtifacts artifacts: 'rollback/verification.json', fingerprint: true
      }
    }
  }

  post {
    always {
      echo "Rollback run ${env.BUILD_NUMBER}: ${currentBuild.currentResult}"
    }
    aborted {
      echo 'Approval or run was aborted. Read target state before any later action.'
    }
    failure {
      echo 'Rollback is not verified. Preserve evidence and escalate with target state.'
    }
  }
}

Đọc outcome đúng cáchCopy Anchor Link

input có timeout và submitter để approval không chờ vô hạn và có identity record, nhưng group name là ví dụ; xác minh security realm và quyền thật. Đặt gate tự động trước input để approver thấy candidate đã được kiểm. Approval timeout hoặc explicit abort không tự chọn rollback khác và không chứng minh deploy stage đã không chạy.

disableConcurrentBuilds() chỉ tuần tự hóa cùng job. lock chỉ bảo vệ các job cũng dùng cùng resource name, vì vậy target platform vẫn cần optimistic concurrency/idempotency và readback state. Không giữ lock khi làm approval; lock chỉ bao deploy và verify. Không bọc deploy, migration assessment hay health gate bằng retry để làm xanh kết quả.

Rollback drill và runbook rehearsalCopy Anchor Link

Rollback drill là rehearsal có giới hạn thời gian, target sandbox/staging, observer và tiêu chí pass/fail. Drill phải chứng minh được con người, evidence và control phối hợp ra sao; nó không chỉ là chạy một lệnh undo.

Diễn tập ít nhất khi thay deploy platform, release manifest, migration framework, feature-flag service, IAM/credential hoặc retention policy; tần suất cụ thể do risk owner đặt. Sau drill, ghi thời gian phát hiện, thời gian quyết định, thời gian khôi phục, bước thủ công, evidence thiếu và action owner. Không tuyên bố RTO/RPO đạt nếu drill không đo chúng.

Lab không-production an toànCopy Anchor Link

Điều kiện và Jenkinsfile labCopy Anchor Link

Lab này chỉ tạo một manifest text và state giả trong workspace Jenkins. Nó không checkout SCM, không dùng credential, không gọi network, không deploy, không tạo container/cluster và không xóa file. Cần Jenkins LTS có Declarative Pipeline, Pipeline: Basic Steps, archiveArtifacts, Linux agent label rollback-lab, shell POSIX và sha256sum. Xác minh plugin/agent trên sandbox; Jenkinsfile tĩnh không chứng minh runtime capability.

Tạo Pipeline job sandbox, chọn Pipeline script, rồi dán Jenkinsfile. SCENARIO mô phỏng quyết định; nó không là action rollback thật.

pipeline {
  agent { label 'rollback-lab' }

  options {
    // Keep the lab self-contained: no implicit SCM checkout occurs.
    skipDefaultCheckout(true)
  }

  parameters {
    choice(
      name: 'SCENARIO',
      choices: ['success', 'unsafe-schema', 'approval-abort'],
      description: 'Creates training-only evidence; no external system is contacted.'
    )
  }

  stages {
    stage('Create immutable training artifact') {
      steps {
        sh '''#!/bin/sh
          set -eu
          LAB_ROOT="$WORKSPACE/rollback-lab-$BUILD_NUMBER"
          mkdir -p "$LAB_ROOT"
          printf '%s\n' 'rollback-training-v1' > "$LAB_ROOT/catalog-api.training"
          sha256sum "$LAB_ROOT/catalog-api.training" > "$LAB_ROOT/SHA256SUMS"
          DIGEST="sha256:$(awk '{print $1}' "$LAB_ROOT/SHA256SUMS")"
          printf '%s\n' "current=sha256:simulated-new" > "$LAB_ROOT/current-state.txt"
          printf '%s\n' "candidate=$DIGEST" > "$LAB_ROOT/decision.txt"
          printf '%s\n' 'schema=backward-compatible-training-only' >> "$LAB_ROOT/decision.txt"
        '''
      }
    }

    stage('Evaluate rollback safety') {
      steps {
        script {
          if (params.SCENARIO == 'unsafe-schema') {
            error 'Intentional lab stop: simulated schema is not safe for binary rollback.'
          }
        }
        sh '''#!/bin/sh
          set -eu
          LAB_ROOT="$WORKSPACE/rollback-lab-$BUILD_NUMBER"
          grep -Fqx 'schema=backward-compatible-training-only' "$LAB_ROOT/decision.txt"
          sha256sum --check "$LAB_ROOT/SHA256SUMS"
        '''
      }
    }

    stage('Simulated approval') {
      steps {
        script {
          if (params.SCENARIO == 'approval-abort') {
            currentBuild.result = 'ABORTED'
            error 'Intentional lab abort before any simulated deployment.'
          }
        }
        echo 'Training approval simulated; no external action is available in this lab.'
      }
    }

    stage('Record simulated rollback verification') {
      steps {
        sh '''#!/bin/sh
          set -eu
          LAB_ROOT="$WORKSPACE/rollback-lab-$BUILD_NUMBER"
          CANDIDATE="$(awk -F= '/^candidate=/ {print $2}' "$LAB_ROOT/decision.txt")"
          printf '%s\n' "verified=$CANDIDATE" > "$LAB_ROOT/verification.txt"
          grep -Fqx "verified=$CANDIDATE" "$LAB_ROOT/verification.txt"
        '''
        archiveArtifacts artifacts: "rollback-lab-${env.BUILD_NUMBER}/current-state.txt,rollback-lab-${env.BUILD_NUMBER}/decision.txt,rollback-lab-${env.BUILD_NUMBER}/SHA256SUMS,rollback-lab-${env.BUILD_NUMBER}/verification.txt", allowEmptyArchive: false
      }
    }
  }
}

Kết quả mong đợiCopy Anchor Link

Lab chỉ xác minh flow file, checksum, outcome stage và behavior runtime của sandbox. Nó không chứng minh input, lock plugin, artifact repository, IAM, database compatibility, feature flag, production deploy hay telemetry. Các file training cần xem lại được archive thành build artifacts và được giữ/xóa theo build/artifact retention policy của job, với quota và ACL phù hợp; retention này không bảo đảm workspace trên agent còn tồn tại. Workspace chỉ là tạm thời và phải được dọn sau build theo policy cleanup của agent/workspace; dùng workspace/job sandbox riêng.

TroubleshootingCopy Anchor Link

Checklist xác minhCopy Anchor Link

• Release record có target logical, current/previous digest, source/build provenance, gate evidence, decision owner và incident/change reference.
• Candidate rollback dùng artifact bất biến còn lấy/verify được; không dùng tag di động hay rebuild source cũ.
• Candidate đã được đánh giá known-good cho environment và config hiện tại, không chỉ từng có build xanh.
• State đích được đọc lại trước action và sau action; timeout/abort không bị diễn giải thành chưa deploy hoặc success.
• Feature flag, traffic và config có owner, audit, fallback/rollback state và đã được rehearsed; chúng không thay artifact rollback.
• Database migration dùng expand/migrate/contract khi phù hợp; destructive migration, backfill và restore có database owner riêng.
• Pipeline chặn PR/fork trước credential release, dùng identity deploy quyền tối thiểu và không in/archived secret.
• Production approval nêu target, current/candidate digest, migration assessment và reference; có timeout và separation of duties theo policy.
• Concurrency có lock hẹp cùng state/idempotency control ở target; deploy và health gate không được retry mù.
• Rollback drill đã đo detection, decision, recovery, evidence retrieval và các bước thủ công; action sau drill có owner/hạn xử lý.
• Lab chỉ dùng data giả, không network/credential/deploy/destructive command và phân biệt static/runtime evidence với production proof.

Nguồn chính thứcCopy Anchor Link

• Jenkins Pipeline Syntax — Declarative Pipeline, when, input, options, post và parameters.
• Using a Jenkinsfile — Pipeline as Code, environment và credential usage.
• Pipeline: Input Step — approval, submitter và input parameters.
• Pipeline: Basic Steps — timeout, retry, stash, archive và interruption behavior.
• Jenkins: Using credentials — scope credential và giới hạn secret exposure.
• Jenkins fingerprints — nối artifact qua các build Jenkins.
• Lockable Resources plugin — lock resource phụ thuộc plugin.
• Jenkins Controller Isolation — tách controller, agent và workload không tin cậy.
• Kubernetes Deployment — rollout status và revision của Deployment.
• Martin Fowler: Feature Toggles — mô hình và trade-off feature flag.

Đọc tiếpCopy Anchor Link