Enterprise AI Project Wiki · Environments, versions, and release
Deployment
Also calledSoftware deployment · Application deployment · Production deployment
Deployment is the controlled process of installing, configuring, or updating an identifiable software or system version in a specified target environment and checking dependencies, database state, permissions, startup, health, and records until the environment reaches its intended running state. A complete deployment identifies the input artifact, target, execution, resulting change, verification evidence, and stop or recovery path—not merely that files were uploaded.
What deployment changes
A build creates an artifact; deployment combines that artifact with a target environment. The same image under different configuration, identity, database, and network conditions produces a different running result, so the deployment change set covers both software and relevant environment state.
A successful command or an open page is not the exit condition. New instances must be ready, dependencies correct, database at the intended version, critical smoke journeys successful, logs and metrics normal, and the environment record reconciled.
Deployment and user exposure can be separated. A new version may run with zero traffic or behind a feature flag and be released later. This avoids coupling technical installation and business availability into one high-risk event.
Inputs and conditions required before deployment
A dangerous deployment begins by answering basic questions after the window opens: which artifact, which account, what database change, and who stops the run if it fails. These are not details to improvise at the console. They are inputs that determine whether the change is executable; automation only applies unresolved ambiguity to the wrong target faster.
- Which immutable object?
Specify product and component version, build, artifact location, and digest. A branch, working tree, or movable `latest` tag is not the formal input.
Input: release manifest, signature, or digest.
- Which exact target?
Identify environment, account, region, cluster, namespace, host, or slot and bind pipeline identity to it instead of relying on similar names.
Input: target ID, environment inventory, and pipeline binding.
- Which state changes accompany it?
List configuration, secret references, certificates, migrations, caches, queues, schedules, flags, and external endpoint changes.
Input: change set and before/after state.
- Which entry gates apply?
Require prerequisite tests, artifact scan, approval, window, backup or restore point, capacity, and dependency availability.
Input: gate results, approver, and window.
- How is success decided?
Predefine health, business smoke, data checks, performance trend, error rate, alerts, and observation time.
Input: checks, thresholds, and evidence locations.
- When must execution stop or recover?
Set stop points for migration, readiness, errors, data, and dependencies, with an owner for rollback, roll-forward, or restore.
Input: stop conditions, recovery plan, and contacts.
Why doesn't a successful pipeline mean deployment is complete?
A green pipeline usually proves that the planned commands finished, not that the target reached the right state. Artifacts, configuration, database state, health checks, critical journeys, observability, and the final inventory must reconcile. If one does not, the deployment remains in verification, recovery, or observation rather than complete.
Lock the window and target
Reconcile authorization, target, current version, concurrent changes, and owners so deployments and manual edits cannot collide.
Retrieve and verify artifacts
Fetch prebuilt artifacts by digest from a trusted repository and verify signature, provenance, dependencies, and scans without rebuilding at the target.
Capture current state
Record application, configuration, database, traffic, instances, and health and create risk-appropriate backup, snapshot, or retained old plane.
Apply infrastructure and configuration
Use infrastructure and configuration automation for resources, identity, networking, secret references, and runtime parameters.
Run compatible data changes
Sequence schema and data migrations with controlled locks, batches, and timeouts and recheck stop and recovery conditions before irreversible work.
Deploy and start
Update instances under the selected in-place, rolling, blue-green, or staged strategy and pass warm-up, startup, readiness, and liveness checks.
Verify technical and business behavior
Run automated verification and critical smoke tests across logs, metrics, traces, queues, database, and integrations during the observation window.
Confirm, record, or recover
Reconcile final state when exit criteria pass; otherwise contain impact and execute traffic reversal, rollback, roll-forward, or restore.
Choosing a deployment strategy
A strategy name does not make a deployment safe. It rearranges when old and new versions coexist, how much extra capacity is needed, how much traffic is exposed first, and how quickly the team can stop or switch back. Choose against data compatibility, sessions, asynchronous work, observable traffic, and tolerable interruption—not familiarity with a label.
| Strategy | Use and principal tradeoff |
|---|---|
| In-place | Updates existing instances with low resource overhead, but failure can cause downtime, overwrite old state, and require redeployment or restore. |
| Recreate | Stops old instances before creating new ones and gives a clear state, but temporarily reduces capacity or interrupts service. |
| Rolling | Replaces instances in batches while capacity remains online. Old and new versions must coexist briefly, so batch observation and stopping are critical. |
| Blue-green | Deploys and verifies a separate new plane before switching traffic and can switch back quickly. It costs more and complicates shared data, sessions, and async work. |
| Canary or waves | Starts with a small set of instances, regions, or requests and expands by metrics. It needs reliable routing, representative traffic, explicit success, and automatic stop. |
| Shadow | Copies real requests to the new deployment without returning its result. Writes, messages, paid calls, and other real side effects must be blocked. |
Why data, configuration, and traffic need separate plans
An application artifact can often be redeployed; business data already written, messages already sent, and external actions already triggered may not be reversible. Configuration and routing also decide what the same code connects to, which authority it holds, and which requests it affects. Their reversibility, evidence, and owners differ, so their plans must be explicit.
Application rollback is not data rollback
Old code might not read a new schema and writes may already exist. Prefer backward-compatible expand, backfill, switch, and contract phases and approve irreversible steps separately.
Configuration is deployed state
Wrong endpoints, roles, flags, or limits change the system even with identical bytes. Version, review, verify, and record configuration; inject secrets by controlled reference.
Deployment and traffic can be decoupled
Create a zero-traffic deployment, pass health and direct tests, then change routing in measured phases with stop and recovery evidence.
Async work needs coexistence
Messages, long transactions, jobs, and consumers may keep old code alive after switching. Schemas and idempotency must tolerate a transition period.
Health is layered
Process liveness, traffic readiness, critical dependencies, business read/write, and end-to-end checks answer different questions; one `200 OK` cannot replace them.
Rollback requires validation
Switching back does not prove recovery. Recheck database, messages, cache, external actions, errors, and backlog and record impact already created.
Deployment records to retain
The record is not there merely to show a green pipeline run. After people move on, the environment changes, or an incident occurs, it must still reconstruct who deployed what, to which target, what actually changed, and how the result was verified. Without that chain, both the current state and the recovery point depend on memory.
- Deployment identity
Unique ID, pipeline run, human or workload identity, approver, start and finish, and target.
- Inputs and changes
Product and component versions, builds, digests, configuration, migrations, infrastructure, and dependencies.
- Execution trail
Step status, logs, retries, manual intervention, deviations, and strategy.
- Verification evidence
Probes, smoke cases, data checks, metrics, alerts, observation window, and results.
- Traffic and feature state
Traffic allocation, feature flags, targeted audience, and change times.
- Final environment state
Running versions and digests, instances, configuration, schema, known issues, and next owner.
- Failure and recovery
Trigger, impact, stop time, rollback or roll-forward, recovery verification, and follow-up issues.
Additional deployment concerns for enterprise AI
Enterprise AI rarely arrives as one synchronized package. Model endpoints, application code, prompts, knowledge indexes, guardrails, and tool permissions can change on separate lifecycles. An endpoint returning `200 OK` proves only that a call path responds—not that answers are grounded, retrieval permissions are correct, or tool actions are safe—so the objects must be linked as one identifiable deployment and verified by layer.
The model is not the only artifact
Model, inference code, runtime image, system prompts, filters, knowledge index, tool definitions, and evaluation configuration form one deployment manifest.
Separate model deployment from endpoint traffic
Deploy a new model and serving environment at zero traffic, test directly or with mirrored requests, then allocate a small percentage before full traffic.
Knowledge has its own lifecycle
Ingestion, permission sync, embedding, indexing, and cache may change without application deployment. Record batch, additions and deletions, retry, visibility, and rollback pointer.
Switch prompts and safeguards coherently
Avoid a new prompt with an old tool or output schema. Deploy related configuration atomically or define compatible ordering and intermediate states.
Block agent side effects first
Zero-traffic, shadow, and test phases use read-only, sandbox, allowlisted, least-privilege credentials until parameters, approval, idempotency, timeout, and human handoff pass.
Observe quality as well as availability
Track refusal, unsupported answer, retrieval, tool failure, handoff, hard-stop events, latency, errors, resource use, and cost.
Revalidate managed-model changes
If provider aliases or behavior can change without your deployment, pin or observe a concrete version and include provider changes in monitoring, evaluation, and recovery.
Concepts commonly confused with deployment
Build makes an artifact available, deployment establishes it in a target, release determines who can use it, go-live moves the change into formal business use, and delivery transfers agreed outputs and responsibility. A project may perform several in one window, but its records and acceptance still need the distinctions; ‘it is live’ does not identify technical state, audience, or ownership.
| Related concept | Difference |
|---|---|
| Build | Build produces an artifact from source and dependencies; deployment applies an existing artifact to a target. Formal artifacts should not be rebuilt there. |
| Release | Release decides which audience receives a prepared version through traffic, flags, or channels. Deployment creates the running state. |
| Go-live | Go-live is the business transition into use and can include deployment, data cutover, audience exposure, communication, and operating handover. |
| Data migration | Migration changes data location, structure, or content and can be a deployment step or an independent project with its own consistency and recovery plan. |
| Configuration management | Configuration management continuously identifies and controls state; a deployment applies an approved state to a target at a point in time. |
| Delivery | Delivery transfers agreed artifacts, documentation, access, and responsibility. Deployment can be one step or be performed by the customer afterward. |
Sources and scope
This entry defines deployment as the technical change that turns specified software and configuration into a runnable, verifiable state in a target environment. It is not identical to build, release, go-live, traffic shift, feature exposure, data migration, or delivery, although one deployment may include some of these actions. Deployment occurs in development, test, UAT, staging, or production, and a production deployment need not expose the new behavior to every user immediately.
- Google Cloud Deploy: Release, target, rollout, deployment, and promotion terminology
- Kubernetes: Declarative deployment, rolling updates, status, pause, and rollback
- AWS Well-Architected: Safe deployment strategies, monitoring, and post-deployment tests
- Microsoft Azure: Immutable packages, staging slots, validation, and deployment automation
- Google Cloud Deploy: Artifact rollout, approval, and audit across target environments
- Azure Machine Learning: Zero-traffic model deployment, mirroring, traffic splitting, and safe blue-green rollout
- Azure Machine Learning: Model, code, environment, endpoint, and deployment resources