Compare intended and effective configuration
A deployment review should explain which settings will change, which settings are expected to stay constant, and how to verify the application after release. A line diff helps, but it can be noisy when files are reformatted or generated in a different order. Prefer comparing semantic configuration when a stable parser is available.
Never upload raw production configuration files containing passwords, private keys, tokens, customer records or internal addresses to a public tool. Even when a web utility processes input locally, corporate device policies and browser extensions can affect data handling.
Build a clear change set
Before deploying, capture the current approved revision, the proposed revision and an explicit expected output. A simple review sequence for a Git-managed project is:
git status --short
git diff --check
git diff --stat
git diff -- README.mdReplace README.md with an authorized configuration path. The commands shown are read-only; avoid mixing examination with staging or committing until the review is complete. For structured JSON APIs, review the changed JSON paths in addition to the raw text diff.
Compare changes against a baseline from the correct branch, environment and deployment target. A diff against the wrong reference may miss changes already merged elsewhere.
Evaluate configuration risk
Check whether any changes alter network exposure, authentication, TLS behavior, message delivery, data retention, permissions, ports or backup handling. For a service behind Cloudflare Tunnel, a seemingly small change from a loopback-only listener to a wildcard listener can materially alter the security boundary.
Separate safety-critical changes from cosmetic differences. Attach tests for parser syntax, service availability and functional behavior. Review newly introduced environment variables and remove secrets from generated sample output before sharing.
Tie the diff to a release and a rollback
Record the Git commit, artifact checksum, approval, deployment window, health-check command and rollback target. The previous configuration should be recoverable through version control or a versioned release without guessing which files changed.
After deployment, confirm both the expected new behavior and the absence of regressions. When the result differs from the approved change set, pause further changes and follow the rollback decision criteria. Do not blindly restore an older database schema over newer writes.
Use the local Line-by-Line Text Diff and API Response Comparator to examine sanitized samples. The former is a readable comparison, not a patch that should be applied automatically.