That's not always possible in an easy way. It leads to more problems than it solves as soon as there are >1 developers. Your code is dependant on a current stat

That's not always possible in an easy way. It leads to more problems than it solves as soon as there are >1 developers. Your code is dependant on a current state of the database and you should factor that in with your deployments. My deployment have a optional Target on the migration for rollbacks and I have never had any problems. Depends on the tech you use ofc. But for. Net the entity framework make it easy. Your comment is only used as a excuse for imperfect deployments and creates too much additional problems. You should really do it like this, so the code decides how the connected database should. Otherwhise the human overhead to execute the correct scripts will have a problem sooner or later ( eg. If a separate team/person handjes deployments). It's also vague to know if someone else has configured everything correct ( at my current job, they put all the scripts in a separate branch. One application connects to another DB and ofc the DB deployments where not configured yet). Urgh