How to organize the rollback of database migrations when rolling back to a previous release?

Question

Software Deployment

Many people use special software for deployment: Capistrano, Deployer, etc. I am no exception, I use Deployer, although in this case it does not matter. Software - php, Laravel, mysql, but this is also not very important, I want to understand the principle.
Such software uses "releases", ie. every time I run the command deploy, a new directory is created on the server, where the latest version of the code from the repository is uploaded and where migrations are performed ( php artisan migrate).
It is also possible to rollback a release, where the latest release is simply removed from the server and the penultimate one is used.
The question is how to fit the rollback of database migrations into this scheme? In general, there are no obstacles - take it and do artisan migrate:rollbackit when calleddeployer rollback. But there is a problem - if there were no migrations at all in the last release. Then a rollback to the penultimate release will roll back migrations that do not need to be rolled back now, because the rollback script is rather stupid, it does not know when to rollback migrations and when not.
How did you actually solve this problem? At the moment, I only rollback migrations manually. Fortunately, the rollback operation is rarely needed. Purely theoretically, you can put a flag file (for example, releaseHasMigration) in the folder with each release. And when rolling back the release, check: if the file exists, you need to roll back. If not, don't do it. But I don't know how to implement such a solution at the Deployer level.
That's why I'm asking a question here. Maybe there are other solutions?

Answer 1

In my opinion, rollback is far from a daily operation and, if necessary, must be performed manually. It's better to test the release more thoroughly...