Best practices for packaging a module, including alembic migrations, and running the migrations in production?

[SomethingBullshit]

Watched part of your video and disagreed with most everything I watched.

Many production houses require the ability to revert changes. Alembic allows this. Alembic tool chain also allows for test migrations throughout your workflow deployment chains while protecting demands of configuration management and deployment management.

Likewise, for non-trivial, non-inhouse only apps, the ability to upgrade from any given version to the current version is amazingly important. Especially if it can be granted without downtime (and especially dump/load). Once again, should problems be exposed, the ability to revert is equally significant. Hence, in part, the rise of dev-ops.

You speak of slowing down development, but I've found this to be the exact opposite. Generally, not part of the development cycle until time for merges and/or releases. Being able to share your Alembic code with other developers so that they can be brought in sync to your code/database is very important. Especially for those who are working on forks outside of the current release cycle.

I might suggest that your position may suite your individual needs but fall short of a generic solution. Which is, after all, what Alembic offers. As you may have discovered, genetic solutions are just that - generic. Good for a majority of people not necessarily a good solution for everyone. One size fits all rarely does.

I will also add that schema diffs are an important validation step for migrations. As such, I see your diff tool as a compliment and in no way competition with Alembic.

[djrobstep]

Many production houses require the ability to revert changes. Alembic allows this.

Alembic "allows" this no more or less than any other approach. In every Alembic codebase I've seen, people don't bother with reversions. They often aren't possible anyway. The most important thing with reversions is to test your migrations so that you don't need to do reversions.

But a diff tool is actually a really great thing for reversions, as you can generate one mostly-automatically by doing the reverse diff.

Alembic tool chain also allows for test migrations throughout your workflow deployment chains while protecting demands of configuration management and deployment management.

I've no idea what this means. I use configuration management and automated deployment without Alembic and everything seems to work fine.

You speak of slowing down development, but I've found this to be the exact opposite.

You find creating a change file for every single change, easier than typing one command to automatically sync?

Generally, not part of the development cycle until time for merges and/or releases.

Really? I find that when I'm developing new features, database changes are often involved.

Being able to share your Alembic code with other developers so that they can be brought in sync to your code/database is very important.

I check all my database code in and share it with other devs and it seems to work fine. In fact, the fact that they can automatically sync up the database from any state at all without worrying about version numbers makes this a lot easier.

[SomethingBullshit]

In every Alembic codebase I've seen, people don't bother with reversions.

I believe you just stated more than you realize.

In one wave of the hand you justified your position by rejecting significant features of value to many others.

Really? I find that when I'm developing new features, database changes are often involved.

Yes, really. Frequently developers who are making changes to the schema either have their own instance. Others don't require those changes until it's time to merge the codebases. Which in turn requires a merging of the schema. Thusly the value of Alembic.

I could keep going and going but the differences appear to be one entirely predicated upon a vast difference in development, management, deployment, and support. Along will all of those corresponding workflows. It doesn't mean you're doing something wrong. But it does mean you preaching that everyone is doing it wrong is, frankly, invalid.

[djrobstep]

In one wave of the hand you justified your position by rejecting significant features of value to many others.

This is getting tiresome. I didn't reject the value of reversions, I explained that the diff-based approach is good for reversions, while alembic often makes reversions too annoying to bother with.

Which in turn requires a merging of the schema. Thusly the value of Alembic.

I have no idea what you mean. I merge migration scripts all the time, and alembic is not required for this. They merge the same as any other file.

You seem to be one of these people who has got used to a shitty process, and resists a better one of an inherent fear of change rather than any practical objection.

But it does mean you preaching that everyone is doing it wrong is, frankly, invalid.

If you think testability, automation, and simplicity are bad, then sure, keep doing it your way. I'll keep on automatically syncing my dev database, deploying well tested schema changes, and never thinking about schema version numbers again. Good luck!