バージョン管理とロールバックの戦略

Each micro frontend deploys independently, yet they run together in the browser. Without disciplined versioning, one bad deploy can break a host that was working moments ago.

The foundation of safe deployment is immutable artifacts: every build produces uniquely named files that are never overwritten.

Adding a content hash to filenames guarantees a changed bundle gets a new URL, so caches and hosts never serve a stale or mismatched file by accident.

A small manifest maps each remote name to the URL currently in production. The host reads it to discover which remote version to load.

Because artifacts are immutable, a deployment is just pointing the manifest to a new version. This makes promotion and rollback a single, fast change.

To roll back, point the manifest entry back to the previous version. Since the old artifact still exists, the rollback is immediate and risk-free.

Serve a new remote version to a small percentage of users via the manifest, watch metrics, then ramp to 100% — or roll back instantly if errors spike.

Use semver for remotes and especially for shared contracts. A major bump signals a breaking interface change that consumers must coordinate around.

Rolling back one remote while others advanced can create shared-dependency mismatches. Keep shared library versions within compatible ranges so any single rollback stays safe.

Wire health checks into the pipeline so a failed post-deploy check automatically reverts the manifest, turning rollback into a hands-off safety net.

Log every manifest change with who, what, and when. This audit trail is invaluable when diagnosing which deploy introduced a regression.

You learned versioning and rollback:

• Use immutable, content-hashed artifacts
• A manifest maps remotes to current versions
• Deploy and rollback by changing the manifest
• Canary per remote and use semver for contracts
• Automate rollback on failed health checks

Disciplined versioning makes independent deploys safe.