Triển khai

Giả sử catalog vừa deploy bộ lọc mới, còn shell và cart không đổi. Người dùng mở tab mới thấy giao diện đúng, nhưng người đang giữ tab cũ chuyển sang một route khác lại gặp lỗi tải chunk. Pipeline catalog vẫn xanh: code mới không nhất thiết sai, nhưng quy trình deploy đã xóa assets mà code cũ còn cần.

Triển khai micro-frontend không chỉ là đưa từng app lên hosting riêng. Bạn cần biết browser đang chạy tổ hợp nào, vì sao tổ hợp đó được chọn và có thể quay về đâu khi có lỗi. Nhóm này nối CI/CD, hosting, runtime configuration, cache và rollout thành một đường release có thể kiểm chứng.

Mục lụcCopy Anchor Link

• Độc lập ở release chứ không chỉ ở repository
• Mô hình triển khai cần giữ trong đầu
  • Artifact selection và runtime đang sống
  • Đường tải của một document mới
• Định danh thứ được build và thứ đang chạy
• Luồng release mặc định
  • Build candidate và giữ đúng bytes
  • Publish đầy đủ graph trước khi đổi selection
  • Kiểm thử đúng tổ hợp trước promotion
  • Promote có kiểm soát và theo dõi hành vi
• Một lần release catalog và rollback
  • Snapshot public mà shell nhận
  • Rollback trên trạng thái hiện tại
• Cache và retention là một phần của release
• Tương thích đặt giới hạn cho tính độc lập
• Phân chia quyền sở hữu và quyền publish
• Điều gì thay đổi với cách tích hợp khác
• Chọn bài đọc theo vấn đề đang gặp
• Bài tập kiểm chứng đường release
• Checklist trước production
• Tài liệu tham khảo
• Các bài trong nhóm

Độc lập ở release chứ không chỉ ở repositoryCopy Anchor Link

Catalog có một repository và một workflow riêng chưa có nghĩa là catalog release độc lập. Nếu mỗi lần đổi bộ lọc đều phải build lại shell, đợi cart merge hoặc nhờ một team chung ghép tất cả source ở HEAD, quyền release vẫn bị buộc vào phần còn lại.

Một thay đổi tương thích của catalog nên có thể đi qua pipeline riêng, ghép với shell và cart đã được hỗ trợ, rồi tiếp cận người dùng mà không cần rebuild hai app đó. Nhưng độc lập không có nghĩa là không cần kiểm tra tích hợp. Catalog vẫn phải giữ public module, props, callbacks, routing và backend contract mà consumers đang dựa vào.

Tách hai hành động để tránh nhầm:

Ba hành động có thể xảy ra gần nhau, nhưng không nên gộp thành một nút không phân biệt outcome. Publish thành công chưa chứng minh candidate đã được chọn; chọn candidate chưa chứng minh người dùng hoàn thành journey; tắt flag không sửa được entry bị lỗi trước khi app đọc flag.

Mặc định mình bắt đầu bằng artifact bất biến và promotion tách khỏi build. Chưa cần một hệ thống canary phức tạp ngay từ đầu. Một đường release đơn giản, có owner và rollback đã diễn tập đáng tin hơn nhiều tầng automation không xác định được release thực chạy.

Mô hình triển khai cần giữ trong đầuCopy Anchor Link

Artifact selection và runtime đang sốngCopy Anchor Link

Có ba lớp trạng thái khác nhau:

Mình hình dung artifact store như kho hàng, selection như phiếu xuất kho. Đổi phiếu quyết định lần lấy hàng tiếp theo, không thay món hàng người dùng đã cầm. Điểm mà phép so sánh này dừng lại là browser còn giữ module trong bộ nhớ và có thể tải thêm lazy chunks của release đã chọn, kể cả sau khi selection đổi.

Vì vậy, rollback pointer và khôi phục toàn bộ người dùng là hai việc khác nhau. Document mới có thể chọn r18 trong khi tab đã chạy r19 vẫn tiếp tục ở r19. Reload có kiểm soát hoặc operational-control channel cần được thiết kế riêng; không mặc định hot-swap remote trong runtime đang sống.

Đường tải của một document mớiCopy Anchor Link

Với shop CSR trong ví dụ, shell là nơi resolve remotes:

direction: right
browser: Browser
shell: Shell HTML + assets
config: "Runtime config\nSnapshot được validate và pin"
catalog: Catalog entry + chunks
cart: Cart entry + chunks
browser -> shell
browser -> config
browser -> catalog: Theo snapshot
browser -> cart: Theo cùng snapshot
config -> catalog: Selection
config -> cart: Selection

Các dòng thể hiện quan hệ tải, không yêu cầu catalog và cart luôn tải tuần tự. Shell có thể lazy-load từng remote khi vào route, nhưng descriptor dùng để resolve vẫn thuộc snapshot của document.

Shell kiểm tra schema, môi trường và URL policy trước khi đưa descriptor cho loader. Nếu config lỗi, chọn failure policy đã công bố: chặn bootstrap hoặc chạy một fallback giới hạn. Đừng âm thầm dùng một snapshot cũ bất kỳ rồi gọi đó là khôi phục thành công.

Remote code chạy cùng trang có thể tiếp cận tài nguyên trong trang theo quyền của JavaScript tại đó. Bởi vậy, quyền sửa remote URL là quyền chọn code được thực thi, không chỉ là quyền sửa một chuỗi cấu hình. Validation URL, HTTPS, CSP và quyền publish cần cùng bảo vệ boundary này; CORS không phải sandbox cho remote.

Định danh thứ được build và thứ đang chạyCopy Anchor Link

Khi có lỗi, “catalog vừa deploy” là thông tin quá mơ hồ. Bạn cần phân biệt ít nhất những định danh sau:

Cùng commit chưa chắc sinh cùng artifact nếu toolchain, dependencies hoặc build environment thay đổi. Approval và test evidence nên gắn với digest của candidate; khi promote, dùng đúng bytes đó thay vì build lại từ commit.

Release set dùng ở pipeline có thể chứa digests, test IDs và metadata nội bộ. Runtime config public chỉ chứa dữ liệu cần cho browser. Hai tài liệu này phục vụ hai boundary khác nhau, không cần ép chúng thành một JSON duy nhất.

Ở runtime, telemetry nên ghi shell release, config revision, selected releases và loaded releases theo phase. Config chọn r19 nhưng entry chưa tải được là một outcome khác với r19 đã mount rồi throw. Giữ metadata release trong artifact giúp đối chiếu điều browser thực sự nhận, thay vì chỉ tin nhãn của publisher.

Luồng release mặc địnhCopy Anchor Link

Luồng dưới áp dụng cho một thay đổi catalog tương thích:

direction: right
n0: "Build candidate"
n1: "Publish artifacts"
n2: "Verify release set"
n3: "Promote"
n4: "Observe"
n0 -> n1 -> n2 -> n3 -> n4

Nếu một gate fail, giữ candidate ở trạng thái chưa được chọn. Việc artifact tồn tại trên storage không buộc bạn phải release nó.

Build candidate và giữ đúng bytesCopy Anchor Link

Pipeline catalog chạy typecheck, tests thuộc phạm vi app, contract verification và production build. Sau đó đóng gói artifact graph, ghi release ID, digest, source SHA và bằng chứng nguồn gốc. Release ID không được tái sử dụng cho bytes khác.

Build once rồi promote qua nhiều môi trường là lựa chọn mặc định khi artifact không nhúng cấu hình môi trường khác nhau. Nếu API URL, public path hoặc server configuration bị đóng vào bundle lúc build, bạn phải gỡ dependency đó hoặc thừa nhận mỗi build theo môi trường là một candidate khác cần kiểm chứng. Đổi biến môi trường ở hosting không tự sửa JavaScript đã build.

Publish đầy đủ graph trước khi đổi selectionCopy Anchor Link

Upload vào prefix riêng, ví dụ https://assets.example.com/catalog/r19/. Prefix phải chứa entry và mọi file mà release tham chiếu, không chỉ remoteEntry.js.

Trước promotion, kiểm tra inventory/digests rồi tải qua CDN và browser ở topology đích. Route lazy, CSS và fonts cần được chạm tới, vì entry trả 200 vẫn có thể dẫn tới chunk sai public path, MIME sai hoặc response HTML từ SPA fallback.

Không cần storage hỗ trợ upload atomic cả thư mục để giữ an toàn cho selection: có thể upload dần trong prefix chưa được chọn, rồi đánh dấu ready sau khi inventory và public-path checks đạt. Chỉ đổi selection khi graph đã đầy đủ; không dùng browser của người dùng làm bước kiểm tra upload cuối cùng.

Kiểm thử đúng tổ hợp trước promotionCopy Anchor Link

Candidate catalog r19 cần được ghép với shell đang phục vụ và cart baseline, không chỉ các app mới nhất trên HEAD. Nếu có nhiều consumer releases còn hỗ trợ, chọn ma trận test theo contract và mức rủi ro; ghi rõ phạm vi được kiểm chứng.

Một gate hợp lý gồm kiểm tra loader/public module, contract, một journey chính và fallback khi catalog lỗi. Test phải dùng artifact sẽ promote. Nếu suite intercept remote bằng component giả, nó không cung cấp bằng chứng cho remote loading.

Preview environment hữu ích ở bước này: candidate catalog ghép với baseline đã pin, URL riêng và backend/dữ liệu test được kiểm soát. Preview không thay production verification, vì CDN rules, auth, cache và dữ liệu ở hai môi trường có thể khác.

Promote có kiểm soát và theo dõi hành viCopy Anchor Link

Publisher tạo một config revision mới trên trạng thái hiện tại, validate rồi commit snapshot nhất quán. Atomic commit tránh đọc nửa JSON; compare-and-swap hoặc transaction tránh một publisher ghi đè promotion của publisher khác. Hai thuộc tính này không thay thế nhau.

Nếu rollout theo cohort, chọn release ở boundary bootstrap, giữ assignment ổn định và pin snapshot trong document. Không chia canary ngẫu nhiên cho từng request entry/chunk: browser có thể nhận graph trộn release. Config được cá nhân hóa cũng không được shared cache phát nhầm cohort.

Sau promotion, kiểm tra document mới từ origin công khai, đối chiếu releases thực load và theo dõi journey outcomes. Gate nên có error/fallback rate, latency, denominator và policy khi thiếu telemetry. “Không thấy exception” không đủ nếu shell đang nuốt lỗi bằng fallback và người dùng không mua được hàng.

Quy trình, workflow và release evidence chi tiết nằm trong CI/CD độc lập; cohort, guardrails và quyết định dừng nằm trong Rollout và rollback.

Một lần release catalog và rollbackCopy Anchor Link

Snapshot public mà shell nhậnCopy Anchor Link

Giả sử shell s17 đang dùng catalog r18 và cart r7. Candidate catalog r19 giữ contract major 1, đã được kiểm chứng với s17 và r7. Sau promotion, endpoint /runtime/config.json có thể trả snapshot dưới đây, khớp schema của bài Runtime configuration:

{
  "schemaVersion": 1,
  "revision": "demo-config-43",
  "environment": "production",
  "apiBasePath": "/api",
  "flags": {
    "newCartSummary": false
  },
  "remotes": {
    "catalog": {
      "enabled": true,
      "scope": "catalog_app",
      "entry": "https://assets.example.com/catalog/r19/remoteEntry.js",
      "release": "r19",
      "contractVersion": 1
    },
    "cart": {
      "enabled": true,
      "scope": "cart_app",
      "entry": "https://assets.example.com/cart/r7/remoteEntry.js",
      "release": "r7",
      "contractVersion": 1
    }
  }
}

Đây là application runtime config do team thiết kế, không phải mf-manifest.json chuẩn của enhanced runtime. Loader classic script trong ví dụ nhận JavaScript entry; không thể đưa một JSON federation manifest vào vị trí đó rồi mong mọi loader tự hiểu.

Shell s17 được nhận diện trong deployment record và telemetry, không nằm trong JSON này. Nếu cần rollback shell, bạn phải dùng cơ chế chọn shell deployment riêng. Đổi schemaVersion, contractVersion hoặc label release cũng không sửa được bytes bên trong artifact.

Rollback trên trạng thái hiện tạiCopy Anchor Link

Giả sử cart đã release r8 độc lập trước khi catalog r19 lộ regression. Lịch sử selection có thể là:

Revert toàn bộ config về revision 42 sẽ rollback nhầm cart. Mặc định tạo revision mới từ snapshot hiện tại, chỉ thay descriptor catalog và giữ thay đổi cart hợp lệ. Tổ hợp s17 + r18 + r8 phải được kiểm chứng; giữ cart r8 không phải một quyết định đúng tự động chỉ vì nó mới hơn.

Nếu publisher khác vừa đổi config, commit rollback phải conflict thay vì force-write snapshot cũ. Đọc lại base, tạo candidate mới và revalidate phần chịu tác động. Audit ghi previous/new release set, actor, lý do và bằng chứng kiểm chứng.

Cache và retention là một phần của releaseCopy Anchor Link

Policy cache phụ thuộc vai trò của URL, không chỉ phần mở rộng .json hay .js:

no-cache cho phép lưu response nhưng yêu cầu validate trước reuse. no-store yêu cầu cache không lưu response; nó không tự xóa một response đã được lưu trước đó. Còn immutable là cam kết nội dung không đổi trong thời gian fresh, không phải công tắc để browser tự phát hiện version mới.

Tên remoteEntry.js không buộc entry phải cache ngắn. /catalog/r19/remoteEntry.js có thể immutable nếu cả release r19 không bị overwrite; /catalog/latest/remoteEntry.js là mutable nếu mỗi lần deploy lại thay bytes. Mặc định chọn release prefix bất biến thay vì trông chờ purge toàn CDN sau mỗi lần release.

Cache đúng vẫn không cứu được tab cũ nếu origin đã xóa lazy chunks. Retention phải bảo vệ active releases, rollback targets và releases thuộc document support window. CDN cache không phải backup: một edge chưa warm hoặc đã evict vẫn cần lấy được file từ origin.

Nếu dùng service worker, thêm lifecycle và cache routing của nó vào quy trình kiểm chứng. curl thấy config mới chưa chứng minh browser đang dùng config mới, và HTTP TTL hết hạn không tự thay snapshot hay module trong bộ nhớ. Chi tiết ở Caching và cache invalidation.

Tương thích đặt giới hạn cho tính độc lậpCopy Anchor Link

Giả sử shell s18 cần export chỉ tồn tại ở catalog r19. Bạn không còn được rollback riêng catalog về r18 khi s18 đang phục vụ. Khi đó cần coordinated recovery đã kiểm chứng hoặc fix-forward; “release trước đó” không mặc nhiên là rollback target hợp lệ.

Mặc định dùng expand–migrate–contract: thêm khả năng mới nhưng giữ contract cũ, chuyển consumers dần, rồi mới bỏ phần cũ khi support window và rollback policy cho phép. Rollout đạt 100% selection không chứng minh mọi tab cũ đã biến mất.

Không cần hỗ trợ mọi release trong lịch sử. Cần một support policy rõ: consumers nào còn được phục vụ, document sống tối đa theo chính sách nào, rollback targets nào được duy trì và xử lý tab hết hạn ra sao. Policy đó quyết định ma trận kiểm thử và retention, không chỉ là ghi chú vận hành.

Với thay đổi backend đã ghi dữ liệu theo semantics mới, rollback frontend có thể gây lỗi thêm. Xử lý dữ liệu và side effects thuộc runbook domain; không chạy migration ngược chỉ vì bạn đã đổi remote mapping.

Phân chia quyền sở hữu và quyền publishCopy Anchor Link

Các team có thể release riêng nhưng vẫn cần một giao diện promotion chung. Điều này không đòi một team platform duyệt thủ công mọi commit; nó đòi policy và quyền được thực thi tại đúng boundary.

Pipeline build cho PR không tin cậy không được có production credentials. Promotion nhận artifact đã được xác thực và quyền publish giới hạn; không nhận remote URL tùy ý từ query string hay PR metadata rồi chạy trên production.

Runtime config là dữ liệu public. Không đưa API secrets, storage credentials hoặc token deploy vào đó. Với preview, cô lập auth và dữ liệu test, chặn production writes, đồng thời có owner và TTL để dọn tài nguyên. Một remote candidate chạy trong shell preview vẫn là code đang thực thi, không phải file vô hại để reviewer mở bằng session production.

Điều gì thay đổi với cách tích hợp khácCopy Anchor Link

Nguyên tắc định danh artifact, kiểm chứng boundary và giữ rollback targets vẫn dùng được ngoài Module Federation. Nhưng đơn vị promotion không giống nhau:

Nếu dùng SSR, chỉ ghi browser remote URL chưa mô tả đủ hệ thống. Cần pin server artifact, browser artifact và dữ liệu config liên quan để tránh server render một version nhưng client hydrate bằng version khác. Không áp dụng nguyên mẫu CSR ở trên như một cấu hình SSR dùng ngay.

Nếu mỗi thay đổi hiện đều cần coordinated release vì public contract đổi liên tục, hãy xem lại boundary trước khi bổ sung automation. Với một nhóm nhỏ và ít nhu cầu release độc lập, modular frontend build chung có thể đơn giản hơn vận hành runtime composition.

Chọn bài đọc theo vấn đề đang gặpCopy Anchor Link

Bạn không cần đọc hết nhóm trước khi xử lý một lỗi cụ thể:

Nếu bắt đầu từ con số không, đọc theo thứ tự CI/CD → hosting → runtime config → caching → rollout/rollback → preview. Đọc thêm Kiểm thử và tooling để chọn bằng chứng ở mỗi gate, và Observability để quyết định dựa trên journey thực thay vì chỉ pipeline status.

Bài tập kiểm chứng đường releaseCopy Anchor Link

Thực hiện trong lab hoặc preview, không chủ động gây lỗi trên production. Nếu lab chưa có cart, dùng shell và catalog trước; bài kiểm tra concurrent release của cart chỉ áp dụng khi app đó đã tồn tại.

1. Chuẩn bị shell s17, catalog r18/r19 và cart r7/r8 nếu có. Ghi digests và pin baseline bằng runtime snapshot hợp lệ.
2. Mở tab A ở catalog r18, nhưng chưa mở một route lazy. Giữ tab đó sống trong suốt bài thử.
3. Publish r19 vào prefix mới, verify inventory và lazy route qua browser/CDN, rồi promote bằng config revision mới.
4. Mở tab B, xác nhận config revision và loaded release là r19; tab A vẫn báo r18. Cho tab A mở route lazy để kiểm tra retention.
5. Nếu có cart, promote r8 độc lập. Tạo rollback catalog trên snapshot hiện tại và verify tổ hợp r18 + r8.
6. Publish rollback bằng concurrency check. Mở tab C để xác nhận target; tab B vẫn ở r19, không được coi là đã tự rollback.
7. Thử fallback khi chặn entry/chunk trong browser context test. Đối chiếu loader error, fallback và journey outcome, không chỉ screenshot.
8. Ghi lại selection history, headers, loaded release set và test evidence. Nếu dùng service worker, lặp lại với các lifecycle cache liên quan.

Bài thử đạt khi bạn chỉ ra được mỗi tab đang chạy release nào, lazy assets của tab cũ còn tải được và rollback không ghi đè một release độc lập hợp lệ. Với concurrent publishers, bổ sung test hai yêu cầu cùng expected version: chỉ một yêu cầu commit, yêu cầu còn lại phải conflict mà không ghi.

Checklist trước productionCopy Anchor Link

• Đơn vị build, deploy và release cùng owner của từng boundary đã rõ.
• Candidate có release ID, digest và test evidence; promotion không âm thầm build lại.
• Release prefix bất biến, graph đầy đủ và được verify qua đường tải công khai trước selection.
• Runtime config không chứa secrets; schema, môi trường và URLs được validate trước bootstrap.
• Document pin một snapshot; selected và loaded releases có telemetry phân biệt.
• Gate kiểm chứng artifact thật với consumers và backend còn được hỗ trợ.
• Publisher có atomic commit, concurrency control, quyền giới hạn và audit.
• Cache policy không phát nhầm cohort; HTML, service worker và bfcache đã được xét theo lifecycle thực tế.
• Retention bảo vệ active documents và rollback targets, không dựa vào CDN làm backup.
• Rollout có guardrails, denominator, missing-data policy và release owner.
• Rollback target còn tương thích, giữ thay đổi độc lập hợp lệ và có kế hoạch cho tab cũ.
• Preview cô lập auth/dữ liệu, có TTL và không cho PR không tin cậy dùng production credentials.

Trước lần release độc lập đầu tiên, ưu tiên làm bài thử tab cũ → promote → rollback ở trên. Nếu chưa tái hiện được release set và đường tải của ba tab, hãy bổ sung metadata và verification trước khi tự động hóa canary.

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

• Micro Frontends — Martin Fowler, Cam Jackson — independent deployment và cách ghép frontend thành một sản phẩm.
• Cache-Control — MDN — semantics của revalidation, no-store và immutable.
• Canary Release — Martin Fowler — release dần và thu hẹp phạm vi ảnh hưởng.

Các bài trong nhómCopy Anchor Link