Rollout và rollback

Giả sử catalog vừa lên r19 và lỗi mở trang sản phẩm bắt đầu tăng. Bạn đổi mapping về r18, nhưng một số người dùng vẫn gặp lỗi: tab của họ đã tải r19, còn một pipeline cart vừa promote thay đổi khác. Nếu chỉ chép lại manifest trước deploy, bạn có thể không sửa được tab lỗi mà còn rollback nhầm cart.

Rollout an toàn cần trả lời ba câu hỏi: ai sẽ nhận release mới, bằng chứng nào cho phép mở rộng, và khi có lỗi thì quay về tổ hợp nào. Rollback là một lần publish có kiểm chứng, không phải nút undo cho mọi trạng thái của browser và backend.

Mục lụcCopy Anchor Link

• Bạn đang rollout thứ gì
• Chọn chiến lược release
• Chọn cohort và pin snapshot
  • Chọn theo người dùng không theo request asset
  • Ví dụ chia bucket ổn định
  • Cache và SSR phải giữ đúng cohort
  • Document cũ không tự chuyển release
• Chuẩn bị đường quay về trước rollout
• Quy trình rollout theo từng đợt
• Đo gì để tiếp tục hoặc dừng
  • Đo release thực chạy và journey outcome
  • Guardrails và quyết định promotion
• Feature flags và kill switch
• Tương thích quyết định khả năng rollback
• Runbook rollback
  • Dừng mở rộng và xác nhận ảnh hưởng
  • Chọn biện pháp giảm ảnh hưởng
  • Tạo snapshot rollback trên trạng thái hiện tại
  • Publish có kiểm soát concurrent writers
  • Kiểm chứng document mới và xử lý tab cũ
  • Xác nhận phục hồi và lưu bằng chứng
• Giữ artifacts và phục hồi khi thiếu files
• Chẩn đoán rollback không có tác dụng
• Bài tập diễn tập rollout và rollback
• Checklist trước production
• Tài liệu tham khảo
• Đọc tiếp

Bạn đang rollout thứ gìCopy Anchor Link

Trong micro-frontend, upload một thư mục và cho người dùng chạy code trong thư mục ấy là hai bước khác nhau. Bạn có thể publish catalog r19 lên CDN mà chưa document nào chọn nó. Tách hai bước này giúp kiểm thử đường tải thật trước khi thay traffic.

Release set là tổ hợp shell, remotes, config và những contract backend cần thiết. Runtime manifest chỉ là phần public mà shell dùng để chọn remote; deployment record cần thêm digests, test evidence, người phê duyệt và rollback target. revision của config khác release của catalog: một config revision mới có thể chọn artifact catalog cũ.

Mặc định mình rollout một thay đổi độc lập mỗi lần trong cùng phạm vi đo. Nếu vừa đổi shell, catalog, cart và flag mới, cohort lỗi sẽ khó chỉ ra thay đổi nào gây regression. Không cần khóa mọi team trên toàn hệ thống; cần giới hạn thay đổi đồng thời ở các boundary có tương tác.

Chọn chiến lược releaseCopy Anchor Link

Mình chọn canary cho remote có traffic đủ lớn và outcome đo được. Với ứng dụng nội bộ ít người dùng, giữ canary 1% có thể không tạo ra bằng chứng nào; preview, một nhóm pilot được hỗ trợ và rollout có giám sát thường thực tế hơn.

Canary không thay contract tests và không phải A/B test. Canary tìm regression để quyết định release; A/B test kiểm chứng giả thuyết sản phẩm với thiết kế thống kê riêng. Cùng dùng cohort không có nghĩa hai mục tiêu này dùng chung gate hay thời gian quan sát.

Chọn cohort và pin snapshotCopy Anchor Link

Chọn theo người dùng không theo request assetCopy Anchor Link

Đừng dùng load balancer phân ngẫu nhiên 5% request /remoteEntry.js vào r19, rồi tiếp tục phân ngẫu nhiên request chunks. Browser cần một artifact graph nhất quán; tải entry của r19 và chunks không tương ứng có thể tạo lỗi ngay cả khi từng build riêng đều đúng.

Chọn release trước khi tải code, rồi trả một config snapshot hoàn chỉnh:

direction: right
n0: "Opaque targeting key"
n1: "Cohort selector"
n2: "Config snapshot"
n3: "Shell bootstrap"
n0 -> n1 -> n2 -> n3

Ví dụ hai nhánh đều giữ shell s17 và cart r7, chỉ catalog thay đổi:

direction: down
stable: "Stable: shell s17 + catalog r18\n+ cart r7"
canary: "Canary: shell s17 + catalog r19\n+ cart r7"

Selector có thể chạy ở server/edge hoặc trong shell nếu policy hoàn toàn public. Server-side selection thuận lợi hơn khi cần cohort từ dữ liệu không công bố cho browser, đồng nhất SSR và audit tập trung. Dù đặt ở đâu, chọn một lần rồi pin snapshot cho document; mỗi remote không tự đánh giá lại policy rollout.

Chọn đơn vị cohort theo nghiệp vụ: user, session hoặc tenant. Nếu nhiều người cùng sửa một workspace, cohort theo tenant có thể tránh trộn hành vi, nhưng một tenant lớn cũng làm traffic lệch mạnh. “5% keys” không đảm bảo “5% requests” hay “5% doanh thu”.

Ví dụ chia bucket ổn địnhCopy Anchor Link

Dùng targeting key ổn định và một namespace không đổi trong suốt rollout. Khi tăng ngưỡng từ 5% lên 20%, nhóm đã được chọn tiếp tục nằm trong canary ở lần bootstrap sau. Không lấy Math.random() mỗi lần fetch config, và không dùng config revision làm namespace vì mỗi promotion sẽ xáo trộn cohort.

Đoạn sau là lab Node.js độc lập, chỉ minh họa assignment, không phải một flag service hay config endpoint. Lưu snippet ở workspace lab rồi chạy node cohort-demo.mjs; không đưa node:crypto vào client bundle.

import { createHash } from 'node:crypto';
import assert from 'node:assert/strict';

function bucketFor(namespace, targetingKey) {
  if (
    typeof namespace !== 'string' || namespace.length === 0 ||
    typeof targetingKey !== 'string' || targetingKey.length === 0
  ) {
    throw new Error('COHORT_KEY_REQUIRED');
  }
  // JSON array tránh ambiguity khi ghép hai string bằng delimiter.
  const digest = createHash('sha256')
    .update(JSON.stringify([namespace, targetingKey]))
    .digest();
  return digest.readUInt32BE(0) % 10_000;
}

function isCanary(namespace, targetingKey, basisPoints) {
  if (
    !Number.isInteger(basisPoints) ||
    basisPoints < 0 || basisPoints > 10_000
  ) {
    throw new Error('COHORT_THRESHOLD_INVALID');
  }
  return bucketFor(namespace, targetingKey) < basisPoints;
}

const namespace = 'catalog-r19-rollout';
const keys = Array.from({ length: 10_000 }, (_, i) => `opaque-${i}`);
const atFive = keys.filter(key => isCanary(namespace, key, 500));
const atTwenty = new Set(
  keys.filter(key => isCanary(namespace, key, 2_000)),
);

assert(atFive.every(key => atTwenty.has(key)));
assert.equal(
  bucketFor(namespace, keys[0]),
  bucketFor(namespace, keys[0]),
);
assert(keys.every(key => !isCanary(namespace, key, 0)));
assert(keys.every(key => isCanary(namespace, key, 10_000)));
assert.throws(() => isCanary(namespace, '', 500));
assert.throws(() => isCanary(namespace, keys[0], 10_001));
console.log('OK: assignment ổn định, tăng ngưỡng giữ cohort cũ');

500 basis points tương ứng 5%; số keys thực tế được chọn chỉ xấp xỉ tỷ lệ ấy. Hash modulo có độ lệch nhỏ và snippet không phải giải pháp phân bổ thống kê cho experimentation. Nếu dùng provider, giữ thuật toán và semantics của provider thay vì giả định nó tạo cùng bucket như lab này. OpenFeature Evaluation Context mô tả targeting key, không áp đặt một thuật toán chia bucket chung.

Key thiếu thì chọn stable hoặc từ chối evaluation theo policy rõ ràng; không tự tạo key mới ở mỗi request. Với khách chưa đăng nhập, anonymous key có thể cần cookie theo privacy policy. Nếu đổi từ anonymous key sang user key sau login, giữ selection hiện tại đến hết document, rồi áp dụng policy mới ở bootstrap tiếp theo.

Không dùng email hay access token làm key trong ví dụ này. Opaque identifier vẫn có thể là dữ liệu cá nhân nếu liên kết được với người dùng; hash không tự biến nó thành anonymous. Đừng gửi key hoặc bucket vào mọi metric label. Override dành cho QA phải được kiểm soát, không là query parameter cho phép người dùng chọn URL remote tùy ý.

Cache và SSR phải giữ đúng cohortCopy Anchor Link

Hai người gọi cùng /runtime/config.json có thể nhận hai release maps khác nhau. Nếu CDN chỉ cache theo URL, response canary của người đầu có thể bị phát cho stable cohort. Lỗi này làm cả rollout lẫn số liệu so sánh không còn đáng tin.

Policy khởi đầu thận trọng cho endpoint chọn theo cookie/user là:

Content-Type: application/json; charset=utf-8
Cache-Control: private, no-store
X-Content-Type-Options: nosniff

Cấu hình CDN thực sự bypass shared cache cho endpoint, và kiểm tra bằng hai browser contexts thuộc hai cohort. Vary: Cookie không thay thế việc kiểm chứng cache key của hosting; service worker cũng phải bỏ qua config endpoint. Với snapshot public giống nhau cho mọi người, có thể dùng revalidation hoặc TTL ngắn, nhưng phải định nghĩa freshness budget. no-cache cho phép lưu rồi validate trước reuse, không đồng nghĩa no-store.

Artifacts của từng release vẫn có thể cache dài với URL bất biến. Không cache immutable endpoint selection mutable, cũng không overwrite /catalog/latest/remoteEntry.js rồi hy vọng purge đưa mọi browser về trạng thái đúng.

Với SSR, chọn release set theo request, render bằng đúng server artifacts và truyền cùng public snapshot cho hydration. Browser không fetch lại rồi chọn canary khác trước hydration. HTML cache phải phân biệt cohort hoặc không shared-cache response cá nhân hóa. Server runtime có module cache sống lâu cần được thiết kế để hỗ trợ nhiều release, hoặc tách deployment/process; đổi URL browser remote chưa đủ để thay module đang render trên server.

Document cũ không tự chuyển releaseCopy Anchor Link

Giả sử tab A pin config 42 chọn r18. Sau khi rollout, tab B pin config 43 chọn r19. Rollback publish config 44 chọn lại r18 sẽ ảnh hưởng document nhận config 44, không sửa snapshot của A hoặc B.

direction: right
a: "Tab A: config 42"
b: "Tab B: config 43"
c: "Tab C: config 44"
r18a: "Catalog r18: tiếp tục r18"
r19: "Catalog r19: tiếp tục r19 sau\nrollback"
r18c: "Catalog r18: document mới sau\nrollback"
a -> r18a
b -> r19
c -> r18c

Ngay cả khi B chưa mở route catalog, snapshot đã pin vẫn có thể khiến nó tải r19 sau rollback. Back/forward cache có thể khôi phục document cũ thay vì bootstrap mới. Chuyển route trong SPA cũng không phải reload document.

Không đổi URL rồi inject r18 vào cùng webpack container scope để “ghi đè” r19. Container, module references và shared singleton đã khởi tạo có thể vẫn giữ trạng thái cũ. Rollback thông thường dùng document mới; hot replacement nhiều release trong cùng runtime là một thiết kế khác, cần loader và lifecycle riêng.

Chuẩn bị đường quay về trước rolloutCopy Anchor Link

Rollback target không chỉ là “release liền trước”. Đó là artifact đã biết tốt và còn dùng được với trạng thái hệ thống hiện tại. Catalog r18 có thể từng hoạt động với shell s17 nhưng không còn đủ exports cho shell s18.

Trước rollout, deployment record cần có:

• Stable và candidate release sets, IDs và digests thực tế; base config revision cùng version/ETag của store.
• Rollback target, artifact inventory và bằng chứng kiểm thử qua CDN, không chỉ từ disk của CI.
• Các shell/remote/backend versions còn được hỗ trợ, flags cần thiết cho từng tổ hợp.
• Owner quyết định promotion, on-call xử lý incident và publisher có quyền rollback.
• Guardrails, volume tối thiểu, cửa sổ quan sát và policy khi thiếu telemetry.
• Cách dừng selection mới, cách xử lý tab đã chạy candidate và nơi lưu audit.

Kiểm tra cả entry và một route có lazy chunks, CSS, ảnh/font. Một request entry trả 200 chưa chứng minh rollback target còn đầy đủ graph. Quy trình CI và CD chi tiết nằm ở CI/CD; layout và public path ở CDN và assets.

Đo thời gian từ quyết định rollback đến lúc document mới thực sự chọn stable. Thời gian đó gồm publish, cache propagation và kiểm chứng; không chỉ thời gian API promotion trả thành công. Thời gian giảm ảnh hưởng ở tab cũ là phép đo riêng, vì code đã tải không tuân theo TTL của config nữa.

Quy trình rollout theo từng đợtCopy Anchor Link

Pause và rollback khác nhau. Pause giữ ngưỡng hiện tại, ngăn tự tăng nhưng vẫn có thể cấp candidate cho document mới trong cohort. Đặt tỷ lệ về 0% ngừng selection candidate mới theo policy đã cập nhật, nhưng không thu hồi snapshot đã phát. Nếu rollout có override nội bộ, emergency stop cần tắt cả override hoặc nêu rõ ngoại lệ điều tra được phép giữ.

Đo gì để tiếp tục hoặc dừngCopy Anchor Link

Đo release thực chạy và journey outcomeCopy Anchor Link

Config nói “muốn tải r19”, không chứng minh r19 đã evaluate và mount thành công. Telemetry nên giữ cả candidate release từ snapshot và release metadata do artifact trả sau load; khi load thất bại, bạn vẫn biết release nào được thử.

Không ghi raw user key, URL query hay dữ liệu giỏ hàng vào payload rollout. Journey IDs là correlation data, không phải metric labels. Release dimensions cũng cần giới hạn cardinality và retention; xem Observability.

Đo journey, không chỉ exceptions. Nếu loader lỗi rồi shell hiển thị fallback, exception có thể được xử lý nhưng người dùng vẫn không xem được catalog. Với journey mở catalog, success là ready theo contract trong deadline; error, timeout hoặc fallback thay catalog đều không phải success. Định nghĩa cancellation và missing data trước khi tính tỷ lệ.

Failure rate = số journey đủ điều kiện không đạt mục tiêu
               / tổng journey đủ điều kiện đã ghi nhận outcome

Tách retry attempts khỏi số journey; một lần mở trang retry ba lần không phải ba người dùng lỗi. Theo dõi coverage của outcome stream và health ingestion, vì browser đóng hoặc telemetry bị chặn có thể làm dashboard đẹp giả.

Guardrails và quyết định promotionCopy Anchor Link

Bảng sau là policy minh họa để diễn tập, không phải cấu hình alert dùng ngay. Trong production, chọn ngưỡng từ baseline, SLO/error budget và mức ảnh hưởng chấp nhận được của sản phẩm.

Chênh lệch 0,5 điểm phần trăm khác tăng tương đối 0,5%. Nếu stable lỗi 1% và canary lỗi 1,5%, chênh lệch là 0,5 điểm phần trăm, tức tăng tương đối 50%. Ghi rõ semantics trong policy để automation không dùng nhầm.

So cùng thời gian và nhóm điều kiện khi có thể. Canary chỉ toàn nhân viên dùng laptop nhanh không phải control hợp lệ cho stable chủ yếu dùng mobile. Cả stable và canary cùng xấu đi có thể do API, CDN hoặc traffic shift; rollout timestamp là manh mối, không phải chứng minh nguyên nhân.

Minimum volume không đảm bảo statistical significance, và việc đọc dashboard liên tục cũng không tự tạo phép kiểm định hợp lệ. Gate tự động cần phương pháp so sánh được thiết kế trước. Với traffic quá thấp, chuyển sang pilot có giám sát thay vì hạ volume đến mức một vài lượt thành công đủ promote.

Mặc định automation không tăng tỷ lệ khi evidence thiếu. Automatic rollback chỉ dùng khi signal, rollback target và concurrency semantics đã được diễn tập; thêm trạng thái pause/cooldown để tránh tự promote rồi rollback lặp lại.

Feature flags và kill switchCopy Anchor Link

Artifact selection và feature flag là hai trục khác nhau. Bạn có thể rollout catalog r19 với một flag tắt, xác nhận load/render, rồi mới mở flag cho hành vi mới. Cách này giảm số biến cần điều tra, miễn cả hai nhánh đã được test.

Flag trong snapshot bootstrap chỉ đổi ở document nhận snapshot mới. Muốn tab cũ phản ứng nhanh, cần một operational-control channel riêng như polling có deadline hoặc push, có contract về độ trễ, failure policy và lifecycle. Channel ấy có thể ngăn thao tác mới hoặc yêu cầu reload an toàn; không hot-swap artifact graph trong runtime đang sống.

Mỗi flag cần owner, default khi evaluation lỗi, ngày xem xét dọn và test cho cả on/off. Đừng để flag cũ trở thành rollback target vĩnh viễn: khi xóa nhánh cũ, khả năng rollback hành vi đó cũng thay đổi và cần ghi vào release record.

Tương thích quyết định khả năng rollbackCopy Anchor Link

Giả sử s17 là shell hiện tại, s18 là shell mới, r18 là catalog stable và r19 là candidate. Những tổ hợp sau cần bằng chứng riêng:

Nếu s18 bắt buộc export chỉ có ở r19, rollback riêng catalog về r18 không còn hợp lệ. Chọn coordinated rollback đã kiểm thử, hoặc fix-forward giữ r19 và sửa lỗi bằng artifact mới. Không chọn release cũ chỉ vì tên nó đứng trước trong danh sách.

Mặc định dùng expand–migrate–contract: provider thêm contract mới nhưng giữ contract cũ; consumers chuyển dần; chỉ bỏ contract cũ sau cửa sổ hỗ trợ và khi rollback targets không còn cần nó. Rollout 100% selection không chứng minh mọi tab cũ đã biến mất.

Tương tự, backend thêm field hoặc endpoint mới theo cách tương thích, hỗ trợ client cũ trong giai đoạn migrate. Nếu r19 đã ghi dữ liệu với semantics mới mà r18 không hiểu, frontend rollback có thể làm tình hình tệ hơn. Việc sửa dữ liệu hoặc bù giao dịch thuộc runbook domain, không chạy migration ngược chỉ vì đã đổi mapping frontend.

Runbook rollbackCopy Anchor Link

Áp dụng khi release có regression hoặc cần thu hẹp ảnh hưởng ngay. On-call xác nhận phạm vi, domain owner xác định target và platform/publisher thực hiện thay đổi selection theo quyền được cấp. Với sai dữ liệu hoặc security incident, ưu tiên chặn thao tác nguy hiểm, không chờ có kết luận đầy đủ về frontend.

jq -e \
  --arg revision 'demo-config-45' \
  --arg release 'r18' \
  --arg entry 'https://assets.example.com/catalog/r18/remoteEntry.js' \
  '
  if .schemaVersion != 1 or .environment != "production"
     or .remotes.catalog.scope != "catalog_app"
     or .remotes.catalog.contractVersion != 1
  then error("Snapshot không khớp policy rollback minh họa")
  else
    .revision = $revision
    | .remotes.catalog.release = $release
    | .remotes.catalog.entry = $entry
  end
  ' current.json > rollback-candidate.json

direction: down
n0: "Input: expected version,\ncandidate, evidence, incident ID"
n1: "Check: quyền, schema,\ncompatibility, inventory, store\nversion"
n2: "Commit: snapshot + revision +\naudit\nHoặc conflict, không ghi"
n0 -> n1 -> n2

Giữ artifacts và phục hồi khi thiếu filesCopy Anchor Link

Giữ mapping rollback mà xóa r18 khỏi storage thì đường quay về chỉ tồn tại trên giấy. Retention phải bao phủ rollback window, document support window và các dependencies được tham chiếu như lazy chunks, CSS, fonts cùng source maps phục vụ điều tra.

Mặc định giữ các release còn active, release được snapshot hỗ trợ tham chiếu và rollback targets; garbage collector không được dựa riêng vào “không còn là latest”. CDN cache không phải bản backup: edge chưa warm hoặc cache đã evict vẫn phải fetch được artifact từ origin.

Tab có thể mở lâu hơn mọi con số retention tùy ý. Cần công bố document support window và cơ chế chuyển tab hết hạn sang trạng thái refresh có kiểm soát, đồng thời backend tiếp tục enforce policy. Access logs “gần đây không ai tải r18” là evidence bổ sung, không chứng minh không còn tab nào giữ r18 trong bộ nhớ.

Nếu rollback target thiếu files:

1. Lấy đúng bytes từ artifact store đã xác thực, đối chiếu inventory/digest.
2. Khôi phục files bị thiếu trong release prefix theo quy trình recovery; không overwrite files hiện hữu bằng bytes khác.
3. Xử lý negative cache của 404 cho các URL được khôi phục và smoke qua CDN/browser.
4. Chỉ đổi selection khi graph và compatibility đã verify lại.

Build lại cùng commit không đảm bảo cùng artifact. Nếu không khôi phục được đúng bytes, tạo release ID mới, kiểm thử như candidate mới; đừng gọi đó là khôi phục release cũ. Nếu stable đã bị xác định có lỗ hổng nghiêm trọng, không rollback vào đó chỉ để giảm lỗi UI; chọn fallback hoặc fix-forward cùng biện pháp containment.

Chẩn đoán rollback không có tác dụngCopy Anchor Link

Bài tập diễn tập rollout và rollbackCopy Anchor Link

Chạy trong lab/preview, không chủ động gây lỗi trên production:

1. Chuẩn bị shell s17, catalog r18/r19, cart r7/r8 và runtime snapshots hợp lệ. Nhúng release metadata vào từng artifact.
2. Tạo hai browser contexts với targeting keys thuộc hai cohort. Xác nhận assignment ổn định qua reload và không trộn config vì shared cache.
3. Mở tab A ở r18; rollout r19 cho tab B. Cho B mở catalog nhưng chưa đi vào một route lazy.
4. Gây lỗi có kiểm soát trong r19, chẳng hạn route throw hoặc chặn một chunk request. Xác nhận loader/journey/fallback telemetry phản ánh ảnh hưởng.
5. Promote cart r8 bằng đường độc lập. Tạo rollback catalog từ snapshot hiện tại; verify candidate giữ cart r8.
6. Cho hai publisher dùng cùng expected store version. Một lượt commit, lượt còn lại phải conflict mà không ghi; rebase và revalidate trước thử lại.
7. Rollback selection sang r18. Tab C mới phải tải r18 + cart r8; tab B vẫn báo r19, không tự chuyển chỉ vì đi route khác.
8. Cho tab A và B mở route lazy sau rollback. Chunks của cả hai release còn tải được trong support window.
9. Thử disable/flag update và reload ở boundary an toàn. Kiểm tra lại khi có service worker hoặc bfcache nếu sản phẩm dùng chúng.
10. Ghi thời gian publish-to-new-document-recovery, ảnh hưởng còn lại ở tab cũ và gaps của telemetry. Bổ sung regression tests cho concurrency, cache và rollback compatibility.

Diễn tập đạt khi bạn chỉ ra được mỗi tab dùng snapshot/release nào, rollback không làm mất cart release độc lập và journey phục hồi có bằng chứng. Một screenshot catalog hiện lại chưa đủ chứng minh quy trình đúng.

Checklist trước productionCopy Anchor Link

• Stable, candidate và rollback target có IDs/digests, artifact inventory và test evidence đúng tổ hợp.
• Artifact graph bất biến, publish trước selection; rollback targets và lazy assets còn đầy đủ.
• Cohort có đơn vị và key ổn định; tăng tỷ lệ không xáo trộn nhóm cũ trong cùng rollout.
• Shell pin một snapshot mỗi document; remote không tự refresh mapping riêng lẻ.
• Config/HTML cache không phát nhầm cohort; SSR và hydration dùng cùng release set.
• Guardrails có denominator, minimum evidence, missing-data policy và outcome cho fallback.
• Flags có default, owner, lifecycle và test cả hai nhánh; backend enforce thao tác nhạy cảm.
• Provider/consumer/backend support window bảo vệ cả tab cũ lẫn rollback targets.
• Publisher dùng revision mới, atomic commit, concurrency check, audit và xử lý outcome không rõ.
• Rollback giữ thay đổi độc lập hợp lệ, không revert mù toàn bộ manifest cũ.
• Có kế hoạch cho tab đã chạy candidate, thao tác chưa lưu và giao dịch đang chờ.
• Đã diễn tập public-path verification, cache/service worker, lazy chunks và conflict giữa hai publishers.

Trước đợt release tiếp theo, chạy thử rollback catalog khi một tab candidate vẫn mở và cart vừa promote độc lập. Đó là bài kiểm tra ngắn nhất để biết đường phục hồi của bạn có hoạt động ngoài happy path hay không.

Tài liệu tham khảoCopy Anchor Link

• Martin Fowler: Canary Release — rollout dần, rollback routing và khác biệt với A/B testing.
• Feature Toggles — tách deploy/release, cohort và lifecycle của flags.
• OpenFeature: Evaluation Context — targeting key và context phục vụ flag evaluation.
• MDN: Cache-Control — semantics của private, no-store, no-cache và immutable.

Đọc tiếpCopy Anchor Link