I wanted to post this earlier but hit the posting limit, so, here it is, with apologies for the delay forced upon me:
Tooling is literally just tools. You can have good ones and bad ones and either use them well or use them poorly. A deployment tool like Capistrano or deploybot is a tool, but so is a shell script that runs rsync the the same way each time it's invoked.
An automated deployment process that involves either zero or minimal human work, (e.g. 'click a button' or 'push to branch X in dvcs') means you get repeatability, and with that comes reliability. How many deploys will be messed up if someone is manually running rsync, because they forgot to exclude some files/dirs, or because they had a trailing slash in a path and things got put 1 directory level too deep?
For DB migrations in particular, I think you're alluding to not using a language/framework/model based migration (e.g. `rails db:migrate`) but instead to use just plain SQL. The difference for me here is whether you're suggesting they literally run the SQL required by hand (e.g. remembering/deducing which migration is required themselves, and either running an SQL file or typing the SQL into an interactive SQL session) or just that plain SQL should be used.
I have positive and negative thoughts about framework/model generated schemas. I think having the model system automatically generate/update schemas based on the model's properties, works fine for a dev environment, but for anything like testing/staging/prod environments, I believe the "best" solution is stored SQL files (preferably in the VCS itself) that are applied automatically by a tool. Those SQL files could be generated as an SQL 'diff' after running the Model generator if you wish, or they could just as easily be hand-written queries. Either way they should be reviewed as with the rest of the code anyway, so their origin is less important than their content.
And yes, I am somewhat "biased" in this: I've written a PHP framework that (amongst other things) will perform model-generated schema changes, and I've written a shell tool (written in shell) that will automatically apply DB migrations and rollbacks from a series of `{up,down}.sql` files.
As explained above, I see the former as a development tool, and the latter as a deployment tool.
Tooling is literally just tools. You can have good ones and bad ones and either use them well or use them poorly. A deployment tool like Capistrano or deploybot is a tool, but so is a shell script that runs rsync the the same way each time it's invoked.
An automated deployment process that involves either zero or minimal human work, (e.g. 'click a button' or 'push to branch X in dvcs') means you get repeatability, and with that comes reliability. How many deploys will be messed up if someone is manually running rsync, because they forgot to exclude some files/dirs, or because they had a trailing slash in a path and things got put 1 directory level too deep?
For DB migrations in particular, I think you're alluding to not using a language/framework/model based migration (e.g. `rails db:migrate`) but instead to use just plain SQL. The difference for me here is whether you're suggesting they literally run the SQL required by hand (e.g. remembering/deducing which migration is required themselves, and either running an SQL file or typing the SQL into an interactive SQL session) or just that plain SQL should be used.
I have positive and negative thoughts about framework/model generated schemas. I think having the model system automatically generate/update schemas based on the model's properties, works fine for a dev environment, but for anything like testing/staging/prod environments, I believe the "best" solution is stored SQL files (preferably in the VCS itself) that are applied automatically by a tool. Those SQL files could be generated as an SQL 'diff' after running the Model generator if you wish, or they could just as easily be hand-written queries. Either way they should be reviewed as with the rest of the code anyway, so their origin is less important than their content.
And yes, I am somewhat "biased" in this: I've written a PHP framework that (amongst other things) will perform model-generated schema changes, and I've written a shell tool (written in shell) that will automatically apply DB migrations and rollbacks from a series of `{up,down}.sql` files.
As explained above, I see the former as a development tool, and the latter as a deployment tool.