Deploy Pipeline

This page traces a single mvn serverless:deploy from configuration files to deployed cloud resources. The whole flow runs in one JVM and shares intermediate results through an in-memory PhaseSession.

Phase Cascade

Each Mojo targets one phase but runs its prerequisites first. The PhaseCascadeExecutor walks a fixed chain, skipping phases the session has already completed and halting the build immediately on the first failure.

Phase cascade chains
The target goal determines the chain. undeploy deliberately runs only validate → undeploy and never triggers plan/deploy/verify.

Between phases, the PhaseSession carries the typed outputs: the validated ComponentRegistry (from VALIDATE) and the ChangePlan (from PLAN). Re-running an earlier phase invalidates everything downstream, so a stale plan can never be fed into deploy.

End-to-End Data Flow

Within the phases, the desired state flows through a series of transformations, ending in real cloud API calls:

End-to-end deploy data flow
Each hop is a distinct module. Italic labels are the artifacts passed between them.

Step by Step

  1. Resolve config files — defaults to src/main/serverless/config.json; multiple files can be declared and are merged in order.
  2. Parse — ConfigurationParser reads each file, resolves file-reference items, and builds a ComponentRegistry of sealed Component records, extracting explicit and implicit ComponentLinks.
  3. Substitute variables — ${...} placeholders are resolved from the variables map before validation.
  4. Validate — Validator runs a fixed chain of rules (cloud provider, application identifier, regions, file references, links, component compatibility, link types, function permissions, authentication, API gateway paths, event bus, database tables, WAF, credentials). All errors are collected; the build fails with the full list rather than the first error.
  5. Plan — a CloudStateReader reads live cloud state, and ChangePlanBuilder classifies each component as create / update / delete / unchanged by comparing configuration hashes. A no-op plan short-circuits deploy.
  6. Derive permissions — for each component about to deploy, every link is turned into narrowly-scoped PermissionGrants (wildcards forbidden).
  7. Deploy — Deployer orders components with a DependencyGraph and calls the provider strategy per component; the AWS strategy dispatches to per-component deployers that make real SDK calls and apply the grants.
  8. Record state — after each success, a StateEntry (name, type, resource id, config hash, timestamp) is added to the manifest, which is always persisted at the end — even on partial failure — so the next run knows what already exists.

Deployment is sequential and halts on first failure: remaining components are reported as pending, already-deployed ones stay recorded in the manifest, and the state lock is always released.

Next: State, Credentials & Multi-Cloud →