Your First Deployment: From Build to Smoke Test

Deployment moves a built application into an environment where real users or testers can reach it. “The deploy succeeded” often means the platform completed its build and upload. You still need to confirm that the right version is live, it can reach its dependencies, and the changed user path behaves as intended.

The exact steps depend on the application and host. This guide covers the durable checks; follow your team’s runbook for production changes.

First identify what you are deploying

Static frontend

A static site produces files such as HTML, CSS, JavaScript, and images. A host serves these artifacts from a CDN. It may need build-time public configuration, but it does not need an application server merely to serve those files. If the frontend calls an API, that API and its data services are separate runtime dependencies.

Application with backend and database

A server-rendered or API application also needs runtime compute, correct environment variables, network access to services, and a compatible database schema. Confirm which parts deploy together and which are managed separately. Do not assume a successful frontend upload migrated a database or restarted a worker.

Before the deploy

1. Identify the commit and target. Confirm the branch or commit, preview/staging/production environment, and deployment trigger.
2. Build from the lockfile. Run the documented build command with the project’s intended runtime version. Inspect the artifact output and warnings.
3. Check configuration. List required variables by environment. Separate public browser-visible configuration from server-only secrets. Never commit secrets or print them into logs.
4. Review service dependencies. Check API URLs, database reachability, background workers, storage, and third-party integrations.
5. Plan schema changes. The new code may be deployed while old code or workers are still running. Use a backward-compatible rollout and follow the database migration plan.
6. Know how to recover. Identify who can roll back, whether the previous artifact is available, and whether the data change is reversible. A code rollback cannot always undo a database write.

Deploy and inspect the result

Watch the platform’s build and deployment logs. Confirm the expected commit, framework command, output directory, and environment. A build error belongs to the build phase; a page that returns an application error after deployment points to runtime behavior or configuration. Keep those categories separate while diagnosing.

After deployment:

• Open the deployment URL in a fresh session and confirm the expected version.
• Check a health endpoint or platform health signal if the application has one.
• Exercise the narrow user journey changed by the release.
• Inspect relevant error logs and latency, plus domain-specific signals such as a completed checkout or processed job.
• Confirm background workers and scheduled tasks are running if the release depends on them.

For a static frontend, verify assets load and API calls reach the correct backend. For a full-stack service, also verify runtime configuration, database connectivity, and a representative read/write path using safe test data where possible.

If something fails

Stop additional rollout when the impact is unclear. Identify whether the failure is in the artifact, environment, network, dependency service, migration, or changed behavior. Use the platform’s logs and compare with the prior healthy release. If the old artifact is safe with the current schema, roll it back according to the runbook. If the schema changed incompatibly or data was transformed, follow the planned forward-recovery procedure and involve the service owner.

Do not run an improvised down migration against live data just because it exists. Recovery must account for what users and background jobs have written since the release.

Deployment checklist

• Correct commit, environment, and build artifact.
• Build and CI checks passed for the intended change.
• Environment variables are set in the right place and secrets remain private.
• API, database, and worker dependencies are reachable.
• Migration order, compatibility window, and recovery plan are clear.
• The changed user journey and relevant health signals were checked afterward.

Practice

For a static site that reads product data from an API, draw the build-time and runtime dependencies. Mark which configuration values are visible in the browser, which are secrets, and what you would check if the site loads but every data request returns 500.