How to do proper post-release steps

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.

I have no experience with this, but there is GitHub - Vetspire-VSP/monarch · GitHub for data migrations. It uses Oban.

I think you may be right there, not all post-release steps should be treated the same - some should require a human to confirm.

For the automatable tasks though, ideally I wouldn’t have to build such a system from scratch

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…

You can run whatever you like at application startup, including delaying some code execution via Oban or regular processes.

In particular, look at application.ex in your Phoenix app. The template looks like this:

There’s even a placeholder for a “worker”.

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

• mix compile.app — Mix v1.20.2
• Application — Elixir v1.20.2

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