I’ve used a number of approaches but usually for a web service I have an endpoint that will trigger applying migrations and a step in the CD pipeline that pings that endpoint.

You can also secure that endpoint to ensure it’s not DDOS’ed.

Interesting. What do you find is the advantage of an endpoint?

If your CD pipeline is run on the same infrastructure as the service i.e. codepipeline in AWS and AWS ECS/EKS, you can expose that endpoint only to the VPN.

I can ensure the migrations are run once on every deployment but if the migration fails I can prevent the service spinning up. Also I can manually rerun if required.

I’m sure there are better ways but this is simple and ensures that migrations are not run for every instance of the service but only once per deployment.

Running on start would run the migration for every instance. So scaling to ten instances would attempt 10 migrations and it’s possible if they’re not written carefully to be idempotent they could interfere with each other.

^^ indeed.

Simplifies to reduce race conditions.

Also it’s easy to test locally.

Another potentially ‘better’ approach is to have an argument to the main fn that only runs the migration and run that once in CD.