Closed decko closed 6 years ago
If it work's I'm in ; )
I've put more thoughts on that and it came to me something against this idea: as a dev and as a community managers I'm always rolling back migrations and sometimes I don't want my database to be at the most recent migration (I like to keep it aligned with master
, so if I change to my dev branch, of to a PR's branch I can apply what they've added, and roll back when stepping back into master
).
If Dockerfile
is always pulling me to the most recent migration this work flow is not so neat and clean IMHO.
Does that make sense or am I overreacting?
Yeah, I've been thinking about your point. Don't you use docker-compose? The "command" parameter on YAML file could overwrite the one in Dockerfile. Maybe this could be a solution for production and development environment. Can I setup a branch and you work with it a couple of days?
I've been running after a solution for this. We don't need to chain it there. We simply could use an extra "command" parameter before the one running gunicorn itself. It will run the migrations before starting the server. But i really want to make easy to first time devs to work on jarbas.
We could create a dockerfile-migrate that is from datasciencebr/jarbas-backend and it just run the migrate command. That way we could have both images available
@caduvieira It wouldn't change the way things are. It would need an extra command to make migrations happen. I'm looking forward a way to help dev and production environment either to have less things to care about.
Closed by inactivity
Every time a Jarbas Docker container starts, the user must run the Django migrate command to reflect the models on database. Since it's the nature of docker containers to be disposable, why don't make docker itself run the django migrate command every time this kind of container starts?
It will not add considerable startup time and also take one less command line to make the deployment and development easier.