django项目migrations文件要不要提交到代码库

怎么会这样!

已于 2022-08-10 16:44:39 修改

阅读量420

点赞数

分类专栏： django 文章标签： django python 后端

于 2022-08-10 11:31:38 首次发布

本文链接：https://blog.csdn.net/qq_24822271/article/details/126263196

版权

django 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

总结：
数据库结构趋于稳定时，生成所有app的迁移文件并提交到master
镜像启动命令中只执行migrate

按照官方的说法，应该提交，并且在服务器端应该直接执行 migrate，无需再次生成。

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into individual migration files - analogous to commits - and migrate is responsible for applying those to your database.
The migration files for each app live in a migrations directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.

中文翻译：
你可以想象 migrations 相当一个你的数据库的一个版本控制系统。makemigrations 命令负责保存你的模型变化到一个迁移文件 - 和 commits 很类似 - 同时 migrate负责将改变提交到数据库。
每个 app 的迁移文件会保存到每个相应 app 的migrations文件夹里面,并且准备如何去执行它, 作为一个分布式代码库。每当在你的开发机器或是你同事的机器并且最终在你的生产机器上运行同样的迁移，你应当再创建这些文件。

Dockerfile

FROM xxxx-base
LABEL maintainer=""
ENV PORT_TO_EXPOSE=30000 devops_env=pro
#COPY operation-platform-server /root/operation-platform-server
ADD . /operation-platform-server
WORKDIR /operation-platform-server
#RUN pip install -r requirements.txt 
# HEALTHCHECK --interval=5s --timeout=3s CMD curl -fs http://localhost:$PORT_TO_EXPOSE/admin/ || exit 1
EXPOSE $PORT_TO_EXPOSE
#COPY docker-entrypoint.sh /
ENTRYPOINT ["/bin/bash","/operation-platform-server/docker-entrypoint.sh"]

/docker-entrypoint.sh

#!/bin/bash
echo "=============init Database=============="
#python manage.py makemigrations
#python manage.py migrate

echo "==============migrate Database==============="
python manage.py migrate

exec gunicorn devops.asgi:application -w 4 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:30000