I once asked this question, but I would be curious to ask it again. In current CI/CD workflows (for example, deploying a docker container to AWS), I am always curious where in their process people include the actual migrations of the table. • Is this in the same docker image as where you serve the API from? The caveat is that you would have to include prisma/cli as dependency in your docker image only for migration-time (which might make the image much heavier)? • Do you use a separate image purely for the migration? And if so, when do you deploy this image?

Hey @Jonathan 👋 Do you perform your migrations currently in a separate workflow before deployment or in the same workflow?

Hey Ryan! We currently have a bash entrypoint script (

CMD bash docker-entrypoint.sh

) defined for our Docker image, which applies the migrations in the same workflow (right after pulling the latest docker-image). This has two problems however: • If migration fails for some reason, the entire script fails. => I suppose it could be fixed with a try-catch in the bash, but I suspect there are better ways to decouple the running of a component from the migrations. • We would need to bundle

@prisma/cli

only to be able to call the migration tool in our Dockerfile, doubling the docker-image size.

We use code pipeline as that is the only way to get access inside the vpc to run the migrations. We run any integration tests, build the container and then build a separate container that just runs the migrations, if everything is successful, then we deploy the build container to ECS. Each step builds its own container and is then discarded or deployed. This may not be the best practice, but its pretty reliable for us.

Hi Dominic, I was curious to Codepipeline as well (I was looking up whether I should apply this in Github Actions / CodePipeline of some sort). So you have a single container (Dockerfile) defined just for the deployments?

yes

Ah yes, you do make a point there. I would want to keep my database private inside the private subnet of the VPC, so perhaps github actions is not really the best way of going

and each step fails then it stops the deployment at that point

though for B/G deployments, since prisma does not technically supports migration rollback, I interpret that for you as writing migrations such that if it exists it does not break the API

correct

Haha, that's what I was hoping github actions to use with as well

no problem

I really appreciate you sharing your workflow, thanks a lot man 🙂 I will no doubt feel a bit more confident thinking about this moving forward

no worries, since we are a startup, our initial one was just deploying through actions and running the migrations manually

I agree with @Dominic Hadfield here and the workflow stated with Codepipeline. If you’re using GitHub Actions you can also initialize the database in your pipeline, run the tests and then perform the migrations on the actual one if publicly accessible. So it would look something like this.

Yeah, when we were performing integration test using github actions, we had an integration test database that was exposed and we would create and drop all tables to do the testing so it didnt matter that it was publicly accessible