#Needs framework manager review

@apotek Hi! I think there is a small misunderstanding.

Drupal Core provides two different hooks to manage updates:
- hook_update_N whose implementations have to be located in .install files and are ran sequentially from the lowest to the highest N value for a given module (hook_update_dependencies can declare dependencies between hook updates from different modules)
- hook_post_update_NAME whose implementations can be located in a .post_update_.php file and are ran sequentially in alphabetical order (these cannot declare dependencies)

Both these hooks are executed when running drush updb or using the update.php route.
It was once possible to separate them with the --no-post-updates option in drush but it is not available anymore.

The need described in this issue was to be able to run code once (like those hooks), after the configuration has been imported because update hooks are meant to be ran before config import. The proposal was to introduce a new hook_post_config_import_NAME hook but it turned out to be a bad idea because we were trying to solve an issue related to the deployment process and not the update process.

This is when drush released their drush deploy command which was running updates, then config import, then a brand new hook they created: hook_deploy_NAME. This solved all issues mentioned above so the development of this post import hook was abandoned.
But, as some people pointed out already, drush is not part of the Core so it would be better to have this in Core than only rely on an external dependency. That's why this issue ✨ Add new route to run deploy hook implementations from the UI Active has been opened (even if its current title can be misleading) .

I hope this helps you understand the current status of this and consider pushing this topic forward in the related issue.

So, in conclusion.

1. The hook that runs database updates is called `hook_update_N()` and lives in the .install(!) file.
2. The hook that runs updates right after the updates and before anything else is done is called `hook_post_deploy_NAME()` instead of (the more logical) `hook_post_update_NAME()`.

(No, developers, `hook_post_deploy_NAME()` does _not_ run after the deployment, even though it is named as though it would and even though it is located in a file called MODULE.post_update.php, and not in the .install file where its sibling `hook_update_N()` is.)

3. Instead of simply providing a way to run steps truly after a deployment has run as requested, the solution is.... a new requirement! You must install drush, and be able to use drush in your environment. Or, you have to do a separate step in the UI.
4. The name of the hook that the Drush project decided to use to run events _after_ a deployment is called :drumroll: .... `hook_deploy_NAME()` and lives in a MODULE.deploy.php file! I kid you not.

After 111 comments and many rejected patches, this is where we are.