Angular / Advanced / Lesson 18

Build, deployment, and upgrade strategy

Treat a release as compatible code, configuration, assets, and hosting behavior, then verify upgrades with the official version and update guidance.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Separate compilation, production output, and hosting responsibilities.
Verify deep links, base paths, and coherent emitted assets.
Plan upgrades from a tested baseline without unsupported latest claims.

A release is more than a successful local build

An Angular release depends on framework and compiler compatibility, lockfile resolution, build configuration, assets, public runtime configuration, and the chosen hosting or SSR mode. A local development page can succeed while a direct deep URL or a stale cached entry point fails after deployment. Record the artifact identity and supported environment. Browser bundles are public, so environment files cannot hold private credentials. These lessons build only isolated local examples and do not deploy, start production services, or modify a configured project. Treat deployment commands and hosting fragments as contextual material requiring an authorized operational workflow.

Keep the entry document and its assets coherent

The complete local model checks whether an entry document’s referenced synthetic assets exist in the selected artifact set. The matching release succeeds and an old entry reference fails. This is a simple consistency model, not an HTTP cache or deployment test. Real deployments need a strategy for HTML freshness, immutable hashed assets, in-flight clients, and lazy chunk availability. Deleting every old asset immediately can break a user who loaded an earlier entry document. Choose retention and cache policy from the application’s actual hosting contract rather than assuming a successful build makes every client update atomically.

typescript Complete local release-asset consistency model

export {};
const artifact = new Set(["main.A1.js", "styles.B1.css"]);
function complete(references: readonly string[]): boolean { return references.every(name => artifact.has(name)); }
console.log(complete(["main.A1.js", "styles.B1.css"]), complete(["main.old.js"]));

Expected output

true false

The line is true false. No filesystem, network cache, host configuration, or deployment is accessed.

Use budgets and configurations as measured policies

Angular build configuration controls the selected builder, output, optimization, and size budgets. The contextual budget fragment below is illustrative for a declared project with its own requirements; its numeric limits are not universal recommendations. A warning or error should lead to understanding dependency growth, not blindly raising every limit. Strict TypeScript and template checks remain separate from browser performance and bundle size. Inspect generated output for source-map exposure and public configuration according to the application’s policy. Keep a clean-build test so cached development artifacts cannot hide missing assets or a dependency that was never recorded in the lockfile.

json Contextual build-budget fragment with illustrative limits

{
  "budgets": [
    { "type": "initial", "maximumWarning": "300kb", "maximumError": "600kb" }
  ]
}

Placed in the appropriate build configuration, the chosen limits would control size diagnostics for that project. No Angular workspace build or size measurement is performed here.

Verify the actual host and supported version combination

Client routing needs direct-path hosting support, and a subpath deployment needs aligned base and asset paths. SSR adds its own server runtime and request-state requirements. Test the artifact under the intended mode rather than treating a development server as deployment evidence. For a new project or upgrade, consult the current official support schedule, compatibility table, and update guide; Angular 20.3 is this course’s tested baseline, not a timeless recommendation or latest-version claim. Upgrade related Angular packages and supported TypeScript/Node versions deliberately, read migrations, and preserve a rollback artifact. Do not run an automated update against a configured project merely to reproduce a lesson.

Deliver a reviewable feature and release checklist

For a capstone, build a course catalog with validated synthetic data, keyed lists, a typed form, explicit route state, a feature-owned store, and deliberate loading/error states. Keep transport replaceable by a testing backend. Verify model computations, DI scope, template compilation, component interaction, accessibility, cleanup, and direct navigation at their appropriate layers. Measure performance only after correctness passes and record limitations honestly. A release check should include artifact identity, public configuration, selected output fields, denied access, base-path behavior, and lazy asset handling. State what was actually executed; local library tests do not certify a deployed browser, SSR server, or cloud hosting system.

Common errors and fixes

Refreshing a deep URL fails after deployment.

Why it happens: The host serves only the root entry path correctly.
How to fix it: Configure and test direct-path handling for the chosen rendering mode.
Prevent it next time: Include deep links and subpaths in release verification.

An old page requests a deleted lazy chunk.

Why it happens: Entry-document and asset retention policies are inconsistent.
How to fix it: Design coherent caching and release-asset retention.
Prevent it next time: Test in-flight clients across release changes.

An upgrade uses incompatible Angular and TypeScript versions.

Why it happens: Packages were updated independently of official requirements.
How to fix it: Select a supported combination and run the relevant migrations and tests.
Prevent it next time: Review support and compatibility before changing the baseline.

Check your understanding

1. The artifact model adds main.C2.js but removes main.A1.js while an older client still references A1. What does the model predict and what policy decision follows?

Show worked solution

The older reference set fails the membership check. A real release must decide how long compatible old assets remain available and how entry documents are cached or refreshed. The model does not prescribe a retention duration, but it makes the coherence requirement explicit. Test the chosen host behavior with an authorized fixture rather than assuming all browsers reload the new entry document immediately.

2. A project starts from this course in a future month. Which version decisions should be rechecked without rewriting every valid model example first?