Hey everyone,
Looking for the best practice for running prisma migrations / prisma client generation during the CI/CD pipeline via CircleCI.
My main question is when / where should this be done being that fly postgres is hidden behind the firewall and not accessible outside of the fly network, so I am guessing running migrations from CircleCI is probably not the best solution.
Is there a way to run migrations as part of the deployment process within fly via Dockerfile or the builtins?
Thanks!
My main question is when / where should this be done being that fly postgres is hidden behind the firewall and not accessible outside of the fly network, so I am guessing running migrations from CircleCI is probably not the best solution.
The default Postgres app configuration does not come with a public-facing port, but this can be configured if required.
You can also use release tasks for this, but I can’t for the life of me find the docs or forum post explaining it!
You’ll want a two phase approach here. One would be to generate the client in the Docker build, like this Apollo Server example: global-apollo-server/Dockerfile at main · fly-apps/global-apollo-server · GitHub
The generated client from yarn build is copied to the final build step.
Then for migrations, add something like this to your fly.toml:
[deploy]
release_command = "npx prisma migrate deploy"
This command will run after the build, but before the image is deployed.
To be clear, the Docker build should not need access to the database to generate the client. The release command will have access to the database.
This was something I was exploring, this only runs “once” correct if we have multiple replicas in the deployment? Didn’t want migrations to be trying to run multiple times at the same time from different nodes.
Yes it should only run once. If it fails, the deploy will fail.