That sounds interesting, would you mind elaborating a bit on what the steps a custom task might help with would be? I assume you mean “bundling” multiple migrate, update, verify operations or is it something else?

We also have a home-grown, so to speak, schema-based multi-tenancy lib that comes with custom mix tasks for handling schema creation/migration for configured tenants (plus the public schema). The actual logic is in separate modules, so that it is callable via mix, e.g. mix app.migrate as well as the release, e.g. /app/release_binary eval 'ReleaseTasks.migrate()', so that it works locally in dev and when deploying.

The lib itself is pretty brute-force I’d say, essentially wrapping all the relevant Ecto.Repo functions, turning the :prefix option into a required parameter, but it works really well for our needs with a minimal amount of magic. Nowadays we could probably use one of the available multi-tenancy solutions, but I think it predates those and we haven’t had the need to switch yet.

As for the potential for an article… Hopefully we’ll get to that, some time. Would need to make up a messy, complex enough use case to walk through. In a nutshell: use the language constructs available - protocols, behaviours (with default, selectively overridable implementations), macros where you need them. In some cases we resorted to just generating function/test clauses in a for comprehension, iterating over some list from the app’s configuration.

As a general theme, I’m very happy with the flexibility working with Elixir/Mix affords. Building entirely custom solutions as needed almost never feels hacky, because you’re working with the tools/frameworks, not against them, if that makes sense.