Force-blocking migrations

[ryanhiebert]

I have on a number of occasions added empty Safe.before_deploy migrations for the sole purpose of blocking my targeted Safe.after_deploy migration until a prior bit of code had been fully deployed.

We could allow migrations to mark themselves as blocking if any dependency migrations have not been deployed previously might meet that need in a better way that doesn't require secondary commits.

[tim-schilling]

I'm having a tough time understanding this. How are you able to get a before_deploy to block an after_deploy?

In the second case, I'm pretty confused. I don't understand the point being made, sorry.

It sounds like (from the title) you want to deploy code with a migration, but not apply it until some condition is met. I'd consider that a application developer problem, not a safemigrate library problem.

For example, you could set it as after_deploy. Then when you're ready to apply it, change the migrations code to before_deploy so the deployment migrates it. But if that is the case and you don't want to apply the migration until the condition is met, don't deploy it.

[ryanhiebert]

I oversimplified my description of the pattern. What do is:

after_deploy -> before_deploy -> after_deploy

The before_deploy migration is empty. It's only purpose is to block the 2nd after_deploy from accumulating on a deployed environment before the first one has finished running.

With this, we can force that certain points in a migration history are checkpoints, where things don't just "roll together" as much as they can anymore. We need to know that it's made it all the way out before it's safe to run these migrations and the code that changed along with it. A good example of that might be a library that wants to give a strong signal that v1 -> v2 should be deployed and migrated before an upgrade v2 -> v3.

---

A similar or related idea is one of "cascading" delays, and I'm not sure if one or the other is superior, or if they are complementary. A cascade delay would be something like

A: after_deploy(delay=timedelta(days=1)) -> B: after_deploy(cascade=True, delay=timedelta(days=1))

Where the delay for B wouldn't begin until its dependencies (A) have completed.

[tim-schilling]

Alright, now I understand you. Thank you. I see the value in it. I do think that use case needs a strong example documented. The library itself doesn't explain how to use it properly and that bit would be very confusing.

The other issue I have is, how common do you think this is? The use case I'm trying to come up with is renaming a FK or ManyToMany field where it's several deployments. I don't know how larger teams manage their migrations. Is it common to erroneously deploy a change before it's ready?

[ryanhiebert]

Logical operations that are complex enough to require this are relatively uncommon, but its not clear to me how much of that is just because of fear. safemigrate is so helpful because it takes fear away from migrations, and I know that this is a place that I have had fear on more than one occasion in the past. But it is infrequent enough that I don't recall exactly what prompted my hacked version of it.

[tim-schilling]

Do you agree we should wait until we have example before implementing this? If no, let's look at what it would do the interface. If it's not making wide changes, it's probably fine to be added.

[ryanhiebert]

I think your examples are good ones. I think that we should include a well-documented example, as you've suggested, so we should at least wait to merge until we have that ironed out. As far as implementation, I think a keyword argument to Safe.after_deploy would be the interface, and my quick guess is that it would add only marginal complexity to the loop where we determine blockers.