Running database migrations before each deployment (and AFTER build steps)
On Heroku, we could declare a
release command which would be run on each deployment. Is there anything similar available on Railway as well?
I ain't using Docker.
19 Replies
No docker required! You can run this as part of a custom build command under settings! Just take your build command and add && php artisan migrate —force
You can also use GitHub actions for this
Railway Blog
Using Github Actions with Railway
Github Actions come with a pretty neat set of features to automate your workflows. In this post, we talk about using Github Actions to automate your deployments on Railway.
I don't see any input field for build command, but start command.
Although the repo I'm playing with has a Dockerfile in it.
If you're using nixpacks which you arnt you can set the env var
NIXPACKS_BUILD_CMD
If your using docker you would just put it as a build step I asume?
Like RUN migrate command
Feels wierd to me tho as you can't build without having a dB up
¯\_(ツ)_/¯There's no database at build time, but at runtime. So adding migration script in the build step on Dockerfile doesn't make any sense to me. Migration should be run just before the deployment takes place.
Quoting from https://junjizhi.medium.com/should-we-run-database-seed-and-migrations-in-dockerfile-4122baecfb5f:
However, even for migrations, I argue that we should avoid running it in Dockerfile. This is particularly for dockerized production environments. Running migrations while building docker image means we can lose control when the migrations will be run. Some database migration could lead to downtime or requires coordination. So running it out of band may be the best option.
Mhmm yea that's what I was saying. But that's the equivalent to the NIXPACKS BUILD CMD.
otherwise you can put it In your exec at the bottom of the docker file
Cooper also mentioned gh actions. Which sounds quite viable to me
Instead, can we implement something like this? Running database migrations isn't really a "build" thing.
Is that a thing or inspect element 👀? It looks convincing
But yea if you put it in the exec command of your docker file it will be the same as a pre release command rn
I asume the start command box only works when using nixpacks unfortunately
I see Nixpacks is already selected (by default) on my service's settings window. 😀
Yea but you said your using a dockerfile 😦
I said. However, I'm wondering if it's automatically picking that up. Isn't there any way to tell Railway not to pick up Dockerfile? Or override that setting?
Ohh
Ughh
By the way, I tried your suggestion on a different platform, and it didn't work. No container was spun up from the image.
Inside
release.sh file:
AAA sorry it's early for me. Instead of exec I meant cmd
I need that coffee
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I defer, not sure what the best practices are 😦
The best practice is to keep Docker image building steps and migrating database separated. We're only discussing about hacky workarounds, and all of 'em have tradeoffs. Heroku implemented it in a proper way, nothing has been proven more effective so far.
https://devcenter.heroku.com/articles/release-phase
Release Phase | Heroku Dev Center
The release phase enables you to run tasks, such as database migrations, before a new release of your app is deployed. If a release phase task fails, the new release is not deployed, leaving the current release unaffected.
What about in a platform agnostic world? Putting them in the CMD step seems somewhat viable to me, if you want them run automatically
Many of the ex Heroku engineers who we've talked to have specified this migration hook/release phase as one of the largest regrets they've ever shipped
Entirely for the reason of it not being extensible nor composable. Which is why we want to allow people to run build steps
Right now you can do that in two ways:
- Adding && to the end of your build step
- Using GitHub Actions