# Staging Deployment — 10.0.0.200

This runbook prepares an operator-led deployment to `10.0.0.200`. It does not authorize or perform deployment. Replace every angle-bracket placeholder through the approved secret and change-management process.

## Required server facts

Before scheduling deployment, confirm the operating system, deployment path, web server, installed PHP version, Composer location/version, MySQL endpoint/database, currently deployed commit, public API URL, HTTPS termination, process supervision, SMPP startup method, firewall rules, and SSH or RDP access. Do not infer these from the IP address.

## Prerequisites

- Approved release commit and change window.
- PHP satisfying `^8.2`, Laravel 12 dependencies, Composer, and MySQL/InnoDB.
- PHP extensions reported by `composer check-platform-reqs --no-dev`, including the PDO MySQL driver.
- A web server whose document root is `<DEPLOYMENT_PATH>/public`.
- HTTPS for the client API and production-mode webhook URLs.
- Write access for the application service account to `storage/` and `bootstrap/cache/`.
- Environment values prepared from `.env.example`; secrets must not be committed or pasted into evidence.
- A dedicated staging tenant, API credential, recipient, sender, webhook receiver, and YAS-approved test window.

## Backup and release identification

1. Record `git rev-parse HEAD`, the release identifier, `php --version`, `composer --version`, `php artisan about`, and `php artisan migrate:status`.
2. Create and verify a restorable MySQL backup using the environment owner's approved tool. Store its identifier, checksum, retention, and restore owner in the change record—never database credentials.
3. Record the current release directory or artifact and the exact rollback commit.
4. Validate migrations against a disposable production-shaped MySQL database before the window.

## Configuration verification

Confirm `APP_ENV`, `APP_DEBUG=false`, retained `APP_KEY`, `APP_URL`, MySQL settings, cache/queue/log settings, tenancy/API limits, message encryption keys, and the exact SMPP variables in [YAS_INTEGRATION_GUIDE.md](YAS_INTEGRATION_GUIDE.md). Never regenerate `APP_KEY` for an existing database.

The repository implements `gateway:smpp:bind-test`, `gateway:sms:send-test`, and one-shot outbox publication. It does **not** implement a persistent SMPP runtime startup or supervision command. The environment owner must identify the approved startup method before GO.

## Operator deployment sequence

From `<DEPLOYMENT_PATH>` after transferring or checking out `<APPROVED_COMMIT>`:

```console
git rev-parse HEAD
composer install --no-dev --optimize-autoloader
composer check-platform-reqs --no-dev
php artisan down
php artisan migrate --force
php artisan optimize
php artisan up
```

Do not run `migrate:fresh`, `db:wipe`, or `key:generate`. For an immutable-release platform, replace the maintenance-mode steps with its approved traffic-switch procedure.

## Post-deployment checks

```console
php artisan about
php artisan migrate:status
php artisan route:list --path=api/v1
php artisan db:show
```

Confirm the implemented RC endpoints, invalid-authentication rejection, tenant isolation, one controlled idempotent submission/replay, distinct full-message and compact-status lookups, webhook configuration, and the staged checks in [STAGING_SMOKE_TEST.md](STAGING_SMOKE_TEST.md). Run external commands only in the approved window:

```console
php artisan gateway:smpp:bind-test yas
php artisan gateway:sms:send-test yas --to=<TEST_MSISDN> --from=<APPROVED_SENDER> --message=<APPROVED_TEST_TEXT> --request-dlr
php artisan gateway:publish-outbox --dry-run --limit=100
php artisan gateway:publish-outbox --once
```

## Rollback criteria and procedure

Declare NO-GO for failed boot, migration, database connectivity, authentication isolation, secret/configuration checks, contract smoke tests, or unexplained data mutation. Stop live tests and preserve sanitized evidence.

Prefer application rollback while retaining additive schema when the previous release is compatible. Schema rollback can remove replay history, DLR evidence, and webhook data and therefore requires database-owner approval and the verified backup. Do not run `migrate:rollback` automatically. If compatibility is unsafe, keep maintenance mode enabled and execute the approved restore plan.

## Evidence package

Capture timestamps, operators, approved commit, dependency/platform checks, migration status before/after, sanitized configuration checklist, route inventory, smoke-test correlation/message IDs, database evidence without contents or secrets, YAS approval/reference, webhook receiver evidence, GO/NO-GO decision, and rollback outcome if used.