How we achieved independent deployments in a micro-frontend architecture

Allegro · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

Hơn 120 team phát triển frontend qua framework nội bộ Opbox (từ 2016). Service opbox-web render toàn bộ frontend và đóng gói hơn 1.200 component/plugin/service (gói npm) làm phụ thuộc.
Deploy theo release train thủ công hai lần mỗi ngày: phải gom đủ tác giả các thay đổi, kỹ sư trực tự dò lỗi và tìm chủ, một thay đổi lỗi phải revert thì cả chuyến chờ.

Thử 1 (bỏ): component dạng FaaS gọi qua HTTP lúc render; chi phí mạng quá cao và không áp được cho mọi phụ thuộc, hai cơ chế song song làm kiến trúc phức tạp hơn; Q2 2024 chuyển hết về component thường.
Thử 2: mở rộng cơ chế sẵn có cho A/B test (nhiều phiên bản một component trong registry, chọn lúc render). Mỗi phiên bản mới mặc định tắt; chủ tự bật trên từng môi trường theo thứ tự: test → Production 0% (chỉ mạng nội bộ) → Production 5% (ít nhất 10 phút) → Production 95%. Bản cũ giữ để lùi nhanh, chỉ xoá khi không môi trường nào dùng.
Thành phần: Developer Portal (Backstage) để quản lý phiên bản; Dependencies Registry giữ trạng thái bật/tắt và lịch sử; Validator kiểm chuẩn (có monitoring, không hại hiệu năng); broker Hermes báo mọi instance opbox-web khi bật/tắt. Môi trường test của team được cài phiên bản động lúc chạy (Node.js không giải phóng được bộ nhớ module đã import nên chỉ dùng ở đó).
opbox-web tự deploy ba lần mỗi ngày làm việc qua canary 0% → 1% → 10% (mỗi bước 10 phút) → 100%, dừng tự động khi có lỗi hay sự cố đang diễn ra; lỗi render được alert thẳng tới on-call của team chủ component.

1.206 phụ thuộc, 126 team; mỗi lần deploy độc lập tiết kiệm khoảng 40 phút; tháng 6/2026 tiết kiệm khoảng 240 ngày công (khoảng 11 FTE).

Tách "deploy code" khỏi "bật phiên bản": service vẫn deploy theo lịch, nhưng mỗi team tự bật phiên bản của mình.
Dùng lại cơ chế đã có (A/B) hơn là thêm một đường thứ hai (FaaS).