Having to do database schema changes manually is HELL. Management seems to not be taking seriously enough the need to stop and implement migrations, my boss/lead dev suggested me to look up how to adopt/implement them in my own free time, instead of stopping all the feature implementing to do this VERY IMPORTANT, CRUCIAL CHANGE. Now I am the retard who takes too much time to do simple changes in the database.

Maybe I am retarded after all.

Liquibase is a decent enough Database SCM tool

why is manually updating schema hell?
Are you changing the type of a column or something?

Big Nope.
Get the approvals in an email, after you warned about the possible problems/damage.
Then drop the production db - "whoopsie. did not mean to do that! good thing I got the approval to do that first!"
Then create the new Schema - clean slate is best!

Manual database schema updates is like storing backups on the same disk of the database server...

You can do it, but if it makes poof it's gone forever.

In case one doesn't understand what I mean... Migrations are versioning. Without versioning, one has no possibility to actually verify / understand the state of the database and it's history.

Zero possibility of inspection/ verification / validation / bisecting.

:-)

@IntrusionCM how do you match code version with database schema version? Do you use corresponding git tags?

@nururururu depends.

Software like Liquibase handles versioning by a "change log"… which is in a nutshell a series of files containing either DDL or DML statements.

These files can be stored in GIT.

Liquibase handles the necessary logic to rollout the changes via configuration, plus a lot more (e.g. changelogs, diff generation current state vs latest, etc.)

In the simplest form, if written manually, it boils down to 2 things:

A) the migrations stored in a VCS with a unique reference (e.g. a GIT tag like v0.1)

B) a tracking table that is updated when the migration ran *successfully*

E.g. a table "migration-version" with an entry "current_version" and then the reference from A.

If done right… one would run the transaction atomically with all migrations from A followed by an update for B.

Most RDBMs support nowadays transaction safe DDLs/ DMLs. Otherwise help of tools like percona-toolkit is necessary to make sure that the migration is atomically - which is the reason why Liquibase and other solutions are definitely easier then a handmade solution. They usually shoulder that burden with support for different RDBMs.

@IntrusionCM thank you very much for the explanation. I'm using Sequelize so I'll have to look into how it's done with that, I suppose. Right now we change the Sequelize model, and then change the database directly instead of allowing it to sync or whatever. It's pretty damn confusing.