I think diff is OK as a verification check after a deployment. But diff is not OK to generate the change script itself.
It's not about abusing the diff. It's about diff being fundamentally the wrong technique to transition from state (C)urrent -> (T)arget.
A diff cannot always bring you to the desired T. The diff only factors in 2 states (C and T) and not X,Y,Z which you may have an import from and which may need to occur during a transitional state before T is reached.
It doesn't factor the desired state T may not even exist to diff against if developers move forward adding objects not for this release. It makes things easier on web developers at the expense of deployments.
Which "scales" better? Migration tools scale better at letting web-devs free wheel in the DB.
For bullet proof deployments migration tools don't scale. They excel at the simple cases but hit a hard limit.
BTW any details on what kind of data in production broke a deployment? Heads up to avoid it myself.
It's not about abusing the diff. It's about diff being fundamentally the wrong technique to transition from state (C)urrent -> (T)arget.
A diff cannot always bring you to the desired T. The diff only factors in 2 states (C and T) and not X,Y,Z which you may have an import from and which may need to occur during a transitional state before T is reached.
It doesn't factor the desired state T may not even exist to diff against if developers move forward adding objects not for this release. It makes things easier on web developers at the expense of deployments.
Which "scales" better? Migration tools scale better at letting web-devs free wheel in the DB.
For bullet proof deployments migration tools don't scale. They excel at the simple cases but hit a hard limit.
BTW any details on what kind of data in production broke a deployment? Heads up to avoid it myself.