A deployment can switch releases successfully and still serve the wrong configuration. I define which source owns each configuration file before combining repository files, environment overlays and preserved local copies.
I then test the copying order with harmless marker values. If an old local file can overwrite the intended replacement, a successful deployment command is hiding an unsuccessful configuration change.
Write the order down
Many deployments combine versioned application files, environment-specific configuration and locally preserved files. Each source can be legitimate. The dangerous part is letting the order emerge accidentally from a sequence of copy commands.
I give each path an owner. If the environment overlay owns a configuration file, the preservation step must not replace it afterwards. If a file is intentionally maintained locally, the deployment should say so rather than quietly pretending it comes from the repository.
Preserve evidence of a disagreement
A hand-edited file in the running release might contain a necessary emergency change. Simply overwriting it can lose useful information. Letting it silently override the intended deployment is no better.
I keep the differing copy in a protected recovery location and report the conflict while applying the documented precedence. The operator can review the difference and move any intended change into its proper source. Configuration containing secrets must stay outside public files and routine logs.
Test the awkward cases
- Deploy a changed overlay and confirm the running release contains the new value.
- Make a different local edit and confirm it is reported and retained for inspection.
- Check an unrelated preserved file still survives.
- Repeat a deployment with no differences and confirm it does not accumulate unnecessary snapshots.
I use harmless marker values in a disposable test site for these checks. There is no reason to print real database credentials to prove which file won.
Remember what PHP is executing
The right file on disk is necessary, but a PHP runtime with timestamp checks disabled may still execute cached code. The PHP OPcache configuration documentation describes that behaviour. The release procedure must refresh the relevant web runtime as appropriate; running a command-line check alone does not establish what PHP-FPM is serving.
This sits alongside an atomic deployment and rollback process. One handles the release switch, the other makes sure the contents of that release are the contents I intended. Both need a clear, testable rule.