What a deployment pipeline owes its developers
Pipelines are usually evaluated on speed. A more useful test is whether an engineer who did not build it can predict what it will do, explain what it did, and undo it.
Predictability comes from building once. If each environment rebuilds from source, you are testing several artifacts and shipping a fourth. Build one, publish it, promote it unchanged; the version in production should be byte-identical to the one that passed the checks.
Explainability is a matter of traceability. Given a running service, an engineer should be able to reach the commit, the build, and the configuration that produced it in a couple of steps. When that chain is broken, incident response starts with archaeology.
Reversibility is the one most often missing. A rollback that requires a person to remember the previous version is not a rollback. Declarative deployment helps here, because the previous desired state is recorded rather than recalled.
If rolling back requires remembering something, you do not have a rollback. You have a person on call who happens to remember.
None of this requires a fashionable toolchain. Most of the improvement in the pipelines I have worked on came from removing manual steps and defining ownership, not from adopting a new platform.