The Complete CI/CD Checklist for Deploying Modern Web & Mobile Apps

Overview

CI/CD for app development is not just a build job. A useful pipeline connects source control, automated validation, artifact creation, deployment, monitoring, and release decisions. The exact tools may vary: a web team might combine a Git provider with a hosted deployment platform, while a mobile team may use a CI service with Fastlane or a comparable automation layer. The underlying controls should remain understandable and portable.

Before changing your workflow, define what “ready to release” means for the application. Record the supported environments, required tests, deployment owner, rollback method, and signals that indicate a failed release. Keep production deployment separate from routine validation when that separation reduces risk. For smaller teams, an approval step before production can provide useful control without making every change manual.

Use the checklist below as a release gate. Mark each item complete, record exceptions, and link to the relevant run, artifact, or incident. For broader production preparation, pair it with the Web App Deployment Checklist. Mobile teams can also compare their process with the Mobile App CI/CD Pipeline Guide.

Checklist by scenario

For every application

• Define the pipeline stages. Separate dependency installation, static checks, unit tests, integration tests, build, security checks, packaging, deployment, and post-deployment verification where appropriate.
• Make the build reproducible. Pin or constrain important dependency versions, commit lockfiles, specify the runtime version, and document required system packages or services.
• Validate the trigger. Run fast checks on pull requests and broader checks on the protected branch. Ensure production deployment cannot be started accidentally from an unreviewed branch.
• Protect secrets. Store credentials in the CI provider’s secret manager or an approved external vault. Do not place tokens, signing keys, private certificates, or production connection strings in source control or build logs.
• Retain useful artifacts. Store test reports, source maps where appropriate, build metadata, and deployable packages according to your operational needs. Every production release should be traceable to a commit and pipeline run.
• Set failure behavior deliberately. A failed test, missing secret, unavailable dependency, or unsuccessful deployment should stop the relevant stage rather than silently passing.
• Test the rollback path. Know whether rollback means redeploying a previous artifact, switching traffic, reverting a configuration, disabling a feature, or restoring a compatible database state.

For web applications

• Run formatting, linting, type checks, unit tests, and integration tests before creating the production bundle.
• Build once and promote the same artifact through staging and production when the platform supports it. Avoid rebuilding separately for each environment.
• Verify environment variables by name and purpose. Keep public client configuration distinct from server-only secrets.
• Run a smoke test after deployment: load the primary route, authenticate a test account if appropriate, exercise a critical API request, and check that static assets resolve.
• Review migration order, cache invalidation, background jobs, and backward compatibility before changing a live service. The database migration strategy guide covers safer schema changes and rollback planning.
• Check performance-sensitive pages and bundles before release. A deployment can be technically successful while introducing a slow route or oversized asset; use the frontend performance workflow when investigating those regressions.

For mobile applications

• Use a clean build environment and verify the required SDK, runtime, dependency, and native tool versions.
• Keep development, staging, and production bundle identifiers or application IDs clearly separated where your release model requires it.
• Store signing certificates, provisioning files, keystores, passwords, and API credentials as protected secrets. Limit access to the smallest group and rotate credentials according to your security process.
• Confirm signing configuration before the release job begins. A pipeline should fail clearly when a certificate is missing, expired, or paired with the wrong application identity.
• Run unit, integration, UI, and device or emulator checks in parallel where they are independent. Reserve the slowest tests for the branches or release candidates that need them.
• Generate version names and build numbers from a documented rule. Prevent reuse of a build number when the target distribution system requires uniqueness.
• Separate artifact creation from store submission when possible. This makes it easier to inspect a package, obtain approval, or retry a submission without rebuilding.

For a GitHub Actions mobile workflow

A minimal workflow should install the required toolchain, restore dependencies, run checks, build a signed artifact, and upload that artifact for review. Use dependency caching only when the cache key includes the lockfile and relevant toolchain inputs. A stale cache must never be trusted as a substitute for a clean, reproducible build.

steps:
  - checkout source
  - restore cache keyed by lockfile and tool versions
  - install dependencies
  - run lint, type checks, and tests
  - build unsigned artifact for validation
  - configure protected signing credentials
  - build signed release artifact
  - upload artifact and test reports
  - deploy or submit only after approval

The syntax differs across CI providers, but the sequence is broadly useful. Keep signing and production submission in a restricted job rather than exposing those credentials to every pull request.

What to double-check

Caching and parallel jobs

Caching can reduce wait time, but an incomplete cache key can hide dependency or compiler changes. Include lockfiles, runtime versions, operating system assumptions, and other material inputs in the key. Provide a straightforward cache-bypass option for debugging. Parallelize independent jobs, then make the deployment job depend on all required checks so a fast path cannot skip a necessary gate.

Secrets and permissions

Use separate credentials for development, staging, and production. Grant read-only access where possible, restrict production credentials to protected branches or approved environments, and mask sensitive values in logs. Review whether third-party actions, plugins, or scripts receive more permissions than they need. A secret that is safe in a deployment job may be inappropriate in a pull-request job run against untrusted changes.

Release safety

Confirm that the application and its backend can tolerate the transition. API changes should remain compatible with clients that have not updated yet; see the API versioning strategy for a release-oriented approach. Add contract tests when services depend on shared request and response formats, using the API contract testing guide as a companion reference.

For high-impact changes, use a staged rollout, a feature flag, or a canary environment. Define the success signals before deployment: error rate, latency, crash rate, job completion, authentication success, or a product-specific workflow. Feature flags are useful only when ownership, expiry, and cleanup are documented; the feature flag strategy guide covers those controls.

Observability and recovery

After release, verify both the deployment system and the application. Check logs, health endpoints, alerts, crash reporting, queue processing, scheduled jobs, and key user journeys. Make sure the team can identify the deployed commit and retrieve the corresponding artifact. Write the rollback command or procedure down before an incident occurs.

Common mistakes

• Testing only after deployment: Production becomes the first integration environment. Move representative checks earlier and reserve production verification for smoke tests.
• Rebuilding for every environment: Different builds can contain different dependencies or generated output. Prefer promotion of a tested artifact where practical.
• Putting secrets in configuration files: Even a private repository can be copied, logged, or exposed through history. Use managed secrets and rotate anything accidentally committed.
• Relying on a green pipeline alone: Automated checks can pass while a DNS record, permission, migration, store setting, or third-party integration is wrong. Keep a short post-deploy checklist.
• Ignoring rollback compatibility: Rolling back application code may not reverse a database migration or external side effect. Plan forward-compatible migrations and compensating actions.
• Over-caching: A cache that is difficult to invalidate can create misleading builds. Optimize only after measuring pipeline time and preserve a clean-build path.
• Allowing every branch to deploy: Limit production deployment to protected branches, approved environments, or explicit release actions.

When to revisit

Run this checklist before each production release, after a major change to the application architecture, and whenever the team changes its CI provider, hosting platform, mobile build tools, signing process, or deployment strategy. Revisit it before seasonal planning cycles so pipeline capacity, test coverage, access reviews, and rollback exercises are not left until release week.

Schedule a formal review at least twice a year, or sooner when a critical tool release or security event changes your assumptions. During the review, inspect failed and slow jobs, remove obsolete secrets, refresh action and plugin versions through a controlled process, confirm cache behavior, and test a recovery path. Keep the checklist in version control so updates are reviewed like code.

For your next release, copy the checklist into the change record, assign an owner to each exception, and attach the final pipeline run and artifact. If the process cannot answer what was deployed, how it was tested, who approved it, and how it can be reversed, stop and close that gap before production.