Hi all, I wanted to ask how the community is dealing with post-release steps.
Today we have Ecto migrations, which make sure that the db has been updated to the new schema etc. before the application starts up.
What I’d need is something similar to migrations but for after the application has started. Sometimes after releasing the new code we need to perform some steps like re-publish some events or re-calculate and store some data, and these steps need the newly-released code to be there.
Today we’re taking care of steps like these by connecting to the running app and issuing the necessary commands by hand. Ideally though we’d be able to script these steps in code (and have them be part of pull requests) and then have them run after the app has started successfully, perhaps even schedule them for e.g. after-work hours. And of course if these steps are scripted in code, we’d only run them once (like how ecto migrations are only run once)
Are you aware of something like this existing in the BEAM ecosystem already? If not, how do you deal with such situations? Do you abuse for example Ecto migrations to run non-db related code? Create one-off Oban jobs? Thanks.
I’d say, for everything which requires some kind of credentials or identification, like inviting or creating users, keep using the manual process. It’s better to have a person do the action than have a script do it unconditionally. For other tasks, you can use eval in scripts to run functions. This is about the invocation.
About the timing, it depends on your deployment target. Approaches might defer when using Kubernetes, AWS Fargate, systemd service on a VPS and so on.
Monarch does seem promising, thanks! It’s oriented around data migration, but I guess always returning an empty list from its query/0 function and then running any kind of custom code I might want in the update/1 callback could work. Maybe I could wrap that Monarch behaviour even to only present the exact semantics I’d need…
Sure, I was just hoping for something off the shelf. But in the end I think I’ll go with my own tailor made version after all, using Monarch as an inspiration
Adding to @rhcarvalho 's point, Mix supports phases, which are executed once the main supervision tree is up and running. I have used this to orchestrate post-start routines. YMMV
The documentation could be clearer about usage, so here’s some example pseudo code.
# mix.exs
def application do
[
mod: {Acme.Application, []},
start_phases: [
sync_events: [],
recalculate_stuff: []
]
]
end
# lib/acme/application.ex
def start_phase(:sync_events, _start_type, _args) do
# Fetch events, yada yada yada
:ok
end
def start_phase(:recalculate_stuff _start_type, _args) do
# Do math, yada yada yada
:ok
end
Start phases are good for codifying steps that must be performed each time the application starts. What this doesn’t get you is the schedule them for e.g. after-work hours piece. However, you could perform that scheduling and apply some conditional logic in these callbacks.
EDIT: This approach may be useful when performing cross-process automation.
Another option is to use handle_continue/2 if you are performing expensive state loading in a GenServer. This callback is useful when a process is slow to initialize, blocking the supervisor from starting its remaining children. Move the expensive stuff from init/1 into one or more handle_continue/2 callbacks and startup may be improved.
start_phases I definitely didn’t know about, thanks!
so basically what I had to do now is something like
# in application.ex
def start(_, _) do
children = [...]
opts = [...]
startup_result = Supervisor.start_link(children, opts)
# now add my conditional logic
if something do
insert_new_post_release_steps()
end
# return the intermediate variable
startup_result
end
which is not quite as elegant as having Supervisor.start_link/2 as the last statement in start/2.
I’ll give start_phases a shot, see if that feels any better
