Django 프로젝트 작업 디렉토리 구조에 대한 모범 사례


173

실제로 올바른 방법이 없다는 것을 알고 있습니다. 그러나 나는 잘 작동하고 모든 개발자와 관리자에게 깨끗하게 유지되는 디렉토리 구조를 만드는 것이 어렵다는 것을 알았습니다. github의 대부분의 프로젝트에는 표준 구조가 있습니다. 그러나 PC에서 다른 파일과 모든 프로젝트를 구성하는 방법은 보여주지 않습니다.

개발 시스템에서 이러한 모든 디렉토리를 구성하는 가장 편리한 방법은 무엇입니까? 이름을 어떻게 지정하고 어떻게 서버에 연결하고 배포합니까?

  • 프로젝트 (작업중인 모든 프로젝트)
  • 소스 파일 (응용 프로그램 자체)
  • 저장소의 작업 사본 (git 사용)
  • 가상 환경 (프로젝트 근처에 배치하는 것을 선호합니다)
  • 정적 루트 (컴파일 된 정적 파일의 경우)
  • 미디어 루트 (업로드 된 미디어 파일 용)
  • 읽어보기
  • 특허
  • 서류
  • 스케치
  • 예제 (이 프로젝트에서 제공하는 애플리케이션을 사용하는 예제 프로젝트)
  • 데이터베이스 (sqlite가 사용 된 경우)
  • 프로젝트에서 성공적인 작업을 위해 일반적으로 필요한 것

내가 해결하려는 문제 :

  • 목적이 명확하도록 디렉토리의 이름.
  • 모든 프로젝트 파일 (virtuenv 포함)을 한 곳에 보관하여 전체 프로젝트를 쉽게 복사, 이동, 아카이브, 제거하거나 디스크 공간 사용량을 추정 할 수 있습니다.
  • 복제하고 싶지 않은 다른 파일의 단일 사본을 유지하면서 전체 애플리케이션, 저장소 또는 virtualenv와 같은 일부 선택된 파일 세트의 사본을 여러 개 작성합니다.
  • 선택한 하나의 디렉토리를 재 동기화하여 서버에 올바른 파일 세트를 배포합니다.

답변:


257

~/projects/디렉토리에 두 가지 종류의 Django "프로젝트"가 있으며 둘 다 약간 다른 구조를 가지고 있습니다.

  • 독립형 웹 사이트
  • 플러그 가능 응용

독립형 웹 사이트

대부분 개인 프로젝트이지만 반드시 그럴 필요는 없습니다. 일반적으로 다음과 같습니다.

~/projects/project_name/

docs/               # documentation
scripts/
  manage.py         # installed to PATH via setup.py
project_name/       # project dir (the one which django-admin.py creates)
  apps/             # project-specific applications
    accounts/       # most frequent app, with custom user model
    __init__.py
    ...
  settings/         # settings for different environments, see below
    __init__.py
    production.py
    development.py
    ...

  __init__.py       # contains project version
  urls.py
  wsgi.py
static/             # site-specific static files
templates/          # site-specific templates
tests/              # site-specific tests (mostly in-browser ones)
tmp/                # excluded from git
setup.py
requirements.txt
requirements_dev.txt
pytest.ini
...

설정

기본 설정은 프로덕션 설정입니다. 다른 파일 (예. staging.py, development.py)에서 단순히 수입 모든 production.py에만 필요합니다 변수를 무시하고.

각 환경마다 별도의 설정 파일이 있습니다 (예 : 생산, 개발. 테스트 (테스트 러너를 위해), 스테이징 (최종 배포 전에 확인으로) 및 heroku (헤 로쿠에 배포)로 설정 한 프로젝트도 있습니다.

요구 사항

오히려 setup.py에 요구 사항을 직접 지정하십시오. 내가 가진 개발 / 테스트 환경에 필요한 것만 requirements_dev.txt.

일부 서비스 (예 : heroku)는 requirements.txt루트 디렉토리에 있어야합니다 .

setup.py

를 사용하여 프로젝트를 배포 할 때 유용합니다 setuptools. 그것은 추가 manage.pyPATH내가 실행할 수 있도록, manage.py직접 (어디서나).

프로젝트 별 앱

나는 이러한 앱을 project_name/apps/디렉토리 에 넣고 상대적 가져 오기를 사용하여 가져 왔습니다.

템플릿 / 정적 / 로캘 / 테스트 파일

이 템플릿과 정적 파일을 각 앱 내부가 아닌 전역 템플릿 / 정적 디렉토리에 넣었습니다. 이 파일들은 보통 프로젝트 코드 구조 나 파이썬을 전혀 신경 쓰지 않는 사람들이 편집합니다. 단독 또는 소규모 팀에서 일하는 풀 스택 개발자 인 경우 앱별 템플릿 / 정적 디렉토리를 만들 수 있습니다. 정말 맛의 문제 일뿐입니다.

로케일에도 동일하게 적용되지만 때로는 별도의 로케일 디렉토리를 작성하는 것이 편리합니다.

테스트는 일반적으로 각 앱 내에 배치하는 것이 좋지만 일반적으로 더 많은 앱이 함께 작동하는 테스트를 수행하는 통합 / 기능 테스트가 많으므로 전역 테스트 디렉토리가 적합합니다.

TMP 디렉토리

프로젝트 루트에는 VCS에서 제외 된 임시 디렉토리가 있습니다. 개발 중에 미디어 / 정적 파일 및 sqlite 데이터베이스를 저장하는 데 사용됩니다. tmp의 모든 내용은 아무 문제없이 언제든지 삭제할 수 있습니다.

Virtualenv

나는 virtualenvwrapper모든 venv를 ~/.venvs디렉토리에 선호 하고 배치 하지만 tmp/함께 보관하기 위해 내부 에 배치 할 수 있습니다.

프로젝트 템플릿

이 설정을 위해 프로젝트 템플릿을 만들었습니다. django-start-template

전개

이 프로젝트의 배포는 다음과 같습니다 :

source $VENV/bin/activate
export DJANGO_SETTINGS_MODULE=project_name.settings.production
git pull
pip install -r requirements.txt

# Update database, static files, locales
manage.py syncdb  --noinput
manage.py migrate
manage.py collectstatic --noinput
manage.py makemessages -a
manage.py compilemessages

# restart wsgi
touch project_name/wsgi.py

rsync대신 사용할 수 git있지만 환경을 업데이트하려면 명령을 일괄 적으로 실행해야합니다.

최근에 [django-deploy][2]단일 관리 명령을 실행하여 환경을 업데이트 할 수있는 앱을 만들었지 만 하나의 프로젝트에만 사용했지만 여전히 실험 중입니다.

스케치와 구배

글로벌 templates/디렉토리 안에 배치 된 템플릿 초안 . sketches/프로젝트 루트에 폴더 를 만들 수는 있지만 아직 사용하지 않은 것 같습니다.

플러그 가능 응용

이러한 앱은 일반적으로 오픈 소스로 게시 할 준비가되어 있습니다. django-forme 에서 아래 예제를 보았습니다.

~/projects/django-app/

docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...

디렉토리의 이름이 명확합니다 (바람직합니다). 테스트 파일을 앱 디렉토리 외부에 넣었지만 실제로는 중요하지 않습니다. 제공하는 것이 중요 README하고 setup.py패키지를 쉽게 설치된다, 그래서 pip.


감사합니다! 나는 당신의 구조를 좋아합니다. 그것은 나에게 유용한 아이디어를 주었다. 요구 사항에 setup.py 사용 및 PATH에 manage.py 설치에 대한 유용한 정보. 마지막으로 어떻게하는지 보여 주시겠습니까? 또한 'tmp'디렉토리에 대한 좋은 지적입니다. 오히려 'local'이라는 이름을 지정하고 나서 'env', 'tmp'및 그 밖의 모든 것을 가질 수 있습니다. 이것은 너무 많은 gitignore 거래 문제를 해결합니다. 새로운 문제는이 이름이 'locale'에 너무 가깝다는 것입니다. 'locale'을 핵심 앱 'project_name'(으)로 이동하는 것이 좋습니다. 나쁜 이름 때문에 구조를 바꾸고 싶지 않습니다. 어떤 제안?
raacer

setup.py를 사용할 때 scripts키워드 인수를 추가하십시오 : github.com/elvard/django-start-template/blob/master/project/…tmp 언제라도 제거 할 수있는 "일시적인 것"을 제안하기 때문에 좋아 합니다. 최상위 locale디렉토리는 필요하지 않으며 어디든지 배치 할 수 있습니다. 나는 정적 / 템플릿 디렉토리와 일치하는 것을 좋아합니다.
Tomáš Ehrlich

다른 파일을 복사하지 않고 소스 파일의 여러 복사본을 만드는 기능에 대한 나의 요구 사항은 직접 해결되지 않습니다. 그러나 git checkout프로젝트 디렉토리를 복제 할 때 하나의 dir 'tmp'만 사용 하거나 제외 하여 목표를 여전히 아카이브 할 수 있습니다 . 따라서 귀하의 구조가 모든 요구 사항을 충족시키는 것으로 보이며 의심의 여지없이 정기적으로 사용하기에 충분합니다. 나는 당신의 대답을 받아들이고 있습니다. 감사합니다.
raacer

감사합니다. "다른 파일을 복사하지 않고 소스 파일의 여러 복사본을 만들 수있는 능력"이라는 말의 의미를 여전히 이해하지 못합니다. 조정 된 rsync 명령이 수행 할 것이지만, 이것이 의미하는 바는 아닙니다 ...
Tomáš Ehrlich

나는 보통 src프로젝트 루트 안에 dir을 만듭니다 . 소스 파일 및 git 저장소 루트의 작업 사본입니다. -이 디렉토리의 여러 사본을 만들 수 있습니다 src, src.bak, src_tmp과에 정도. 같은 다른 비의 repo DIRS env, tmp, media, backup같은 수준에 있습니다. 따라서 cp -r src src.bak언제든지 git으로 실험하거나 외부 도구와 버전을 비교하고 싶습니다. 저장소 안에 로컬 파일이 있지만 로컬 파일 디렉토리 안에 저장소가 있습니다 (그 반대도 마찬가지입니다). 내 src디렉토리 의 더 나은 이름은 입니다 repo.
raacer

19

내 대답은 내 자신의 작업 경험에서 영감을 얻었으며 주로 장고의 두 가지 특종 책 과 모든 것에 대한 자세한 설명을 찾을 수 있습니다. 나는 단지 몇 가지 요점에 대답 할 것이며 개선이나 수정은 환영받을 것입니다. 그러나 동일한 목적을 달성하기 위해 더 정확한 방법이있을 수도 있습니다.

프로젝트
개인 디렉터리에 작업중인 모든 프로젝트를 유지 관리하는 기본 폴더가 있습니다.

소스 파일
개인적으로 django 프로젝트 루트를 프로젝트의 저장소 루트로 사용합니다. 그러나 책에서 두 가지를 분리하는 것이 좋습니다. 이것이 더 나은 접근 방식이라고 생각하므로 프로젝트에서 점진적으로 변경을 시작하기를 바랍니다.

project_repository_folder/
    .gitignore
    Makefile
    LICENSE.rst
    docs/
    README.rst
    requirements.txt
    project_folder/
        manage.py
        media/
        app-1/
        app-2/
        ...
        app-n/
        static/
        templates/
        project/
            __init__.py
            settings/
                __init__.py
                base.py
                dev.py
                local.py
                test.py
                production.py
            ulrs.py
            wsgi.py

저장소
Git 또는 Mercurial은 Django 개발자들 사이에서 가장 인기있는 버전 제어 시스템 인 것 같습니다. 백업 GitHubBitbucket에 가장 많이 사용되는 호스팅 서비스입니다 .

가상 환경
virtualenv와 virtualenvwrapper를 사용합니다. 두 번째 것을 설치 한 후에는 작업 디렉토리를 설정해야합니다. Mine은 virtualenvwrapper 설치 안내서에서 권장하는대로 / home / envs 디렉토리에 있습니다. 그러나 가장 중요한 것은 어디에 배치되어 있다고 생각하지 않습니다. 가상 환경에서 작업 할 때 가장 중요한 것은 requirements.txt 파일을 최신 상태로 유지하는 것입니다.

pip freeze -l > requirements.txt 

정적 루트
프로젝트 폴더

미디어 루트
프로젝트 폴더

README
리포지토리 루트

라이센스
리포지토리 루트

문서
리포지토리 루트. 이 파이썬 패키지는 문서를보다 쉽게 ​​관리 할 수 ​​있도록 도와줍니다.

스케치


데이터 베이스


경험을 공유해 주셔서 감사합니다. 구조에는 많은 'project *'디렉토리가 있습니다. 실생활에서 그런 이름을 사용하지 않습니까? 우리가 'todo'프로젝트를 가지고 있다고 가정 해 봅시다. 이 경우에 이러한 디렉토리 이름을 어떻게 지정합니까? 현재 구조에서 볼 수있는 문제는 저장소를 비 저장소 파일과 혼합하는 것입니다 (위에서 언급했듯이). .gitignore에 휴지통을 추가하는 것은 성 가시지 않습니까? 또 다른 모호한 점은 env 디렉토리를 프로젝트 자체에서 멀리 유지하는 것입니다. 말이 되나요? ~ / docs, ~ / statics 등을 생성하지 않는 이유는 무엇입니까? git조차도 소스 파일 근처에 앉아 싶어합니다.
raacer

이름을 "todo_project"-> todo-> todo (또는 todoapp)로 지정합니다. 나는 그것이 이혼자 계층의 루트에있는 저장소 폴더에 중요하다고 생각합니다. 그러나 내 의견 일뿐입니다. 환경 디렉토리에 대해서는 프로덕션 환경을 설정해야 할 때 다음과 같이 입력하면됩니다. pip install -U -r requirements.txt. 그러나 내가 말했듯이 모든 것을위한 하나의 솔루션은 없습니다.
cor

메인 앱의 경로는 "projects / todo_project / todo / todo"입니다. "프로젝트"라는 단어가 두 번 반복되고 "todo"라는 단어가 세 번 반복되었습니다. 이것은 "projects / project / my_project / project_dir / project / project"처럼 보입니다. 이름이 명확하지 않습니다. 이것은 내 디렉토리 구조에서 해결하려는 주요 문제 중 하나입니다. 계층 구조를 쉽게 이해할 수 있도록 디렉토리 이름을 지정하고 싶습니다. 저장소 루트는 어떻습니까? 중요한 이유를 설명해 주시겠습니까? 또한 주요 프로젝트 디렉토리 외부에 envs를 유지하는 것이 좋은 점을 설명해 주시겠습니까?
raacer

13

settings/디렉토리 를 만들고 싶지 않습니다 . 나는 단순히라는 이름의 파일을 추가 settings_dev.py하고 settings_production.py난을 편집 할 필요가 없습니다 BASE_DIR. 아래의 접근 방식은 기본 구조를 변경하지 않고 증가시킵니다.

mysite/                   # Project
    conf/
        locale/
            en_US/
            fr_FR/
            it_IT/
    mysite/
        __init__.py
        settings.py
        settings_dev.py
        settings_production.py
        urls.py
        wsgi.py
    static/
        admin/
            css/           # Custom back end styles
        css/               # Project front end styles
        fonts/
        images/
        js/
        sass/
    staticfiles/
    templates/             # Project templates
        includes/
            footer.html
            header.html
        index.html
    myapp/                 # Application
        core/
        migrations/
            __init__.py
        templates/         # Application templates
            myapp/
                index.html
        static/
            myapp/
                js/  
                css/
                images/
        __init__.py
        admin.py
        apps.py
        forms.py
        models.py
        models_foo.py
        models_bar.py
        views.py
    templatetags/          # Application with custom context processors and template tags
        __init__.py
        context_processors.py
        templatetags/
            __init__.py
            templatetag_extras.py
    gulpfile.js
    manage.py
    requirements.txt

나는 이것을 생각 해요:

    settings.py
    settings_dev.py
    settings_production.py

이것보다 낫다 :

    settings/__init__.py
    settings/base.py
    settings/dev.py
    settings/production.py

이 개념은 다른 파일에도 적용됩니다.


나는 보통 배치 node_modules/bower_components/기본에서 프로젝트 디렉토리에 static/폴더.

언젠가 vendor/Git 서브 모듈을위한 디렉토리이지만 보통 static/폴더에 넣습니다 .


4

다음은 내 시스템에서 수행하는 내용입니다.

  1. 모든 프로젝트는 하십시오이 폴더 내 집의 프로젝트 디렉토리~/projects. 모든 프로젝트는 그 안에 있습니다.

  2. 개별 프로젝트 : 저는 개별 프로젝트를 위해 django-skel 이라는 많은 개발자들이 사용 하는 표준화 된 구조 템플릿을 따릅니다 . 기본적으로 모든 정적 파일 및 미디어 파일을 관리합니다.

  3. 가상 환경 : 집 안에 virtualenvs 폴더 가있어서 모든 가상 환경을 시스템에 저장합니다 ~/virtualenvs. 이것은 내가 가지고있는 모든 가상 환경을 알고 쉽게 사용할 수있는 유연성 을 제공합니다.

위의 3은 My working environment의 주요 파티션입니다.

언급 한 다른 모든 부분 은 대부분 프로젝트마다 다릅니다 (즉, 프로젝트마다 다른 데이터베이스를 사용할 수 있음). 따라서 그들은 개별 프로젝트에 상주해야합니다.


감사합니다. 저장소를 비 저장소 파일과 혼합 할 때 휴지통을 .gitignore에 추가하는 것이 성 가실 수 있습니다. 안 그래? 내 프로젝트 중 일부에는 최대 10 개 이상의 파일과 디렉토리가 있으므로 실제 문제가됩니다. 또 다른 모호한 점은 env 디렉토리를 프로젝트 자체에서 멀리 유지하는 것입니다. 그러한 솔루션의 유연성은 무엇입니까? ~ / docs, ~ / statics 등을 생성하지 않는 이유는 무엇입니까? git조차도 소스 파일 근처에 앉아 싶어합니다. 나는 복사 / 단지 때 유연성이 생각 이동 / 보관 / VIRTUALENV을 포함한 전체 프로젝트 디렉토리를 제거하고 쉽게 하나 개의 프로젝트 내에서 여러 envs을 유지할 수 있습니다
raacer

4

Django Project Skeleton에 따라 따라야 할 적절한 디렉토리 구조는 다음과 같습니다.

[projectname]/                  <- project root
├── [projectname]/              <- Django root
   ├── __init__.py
   ├── settings/
      ├── common.py
      ├── development.py
      ├── i18n.py
      ├── __init__.py
      └── production.py
   ├── urls.py
   └── wsgi.py
├── apps/
   └── __init__.py
├── configs/
   ├── apache2_vhost.sample
   └── README
├── doc/
   ├── Makefile
   └── source/
       └── *snap*
├── manage.py
├── README.rst
├── run/
   ├── media/
      └── README
   ├── README
   └── static/
       └── README
├── static/
   └── README
└── templates/
    ├── base.html
    ├── core
       └── login.html
    └── README

최신 디렉토리 구조는 https://django-project-skeleton.readthedocs.io/en/latest/structure.html 을 참조하십시오 .


7
[프로젝트 이름] / [프로젝트 이름] 접근 방식이
싫습니다

1
django-project-skeleton은 "Django Documentation"이 아닙니다. "django-project-skeleton에 따라 ..."라고 말하는 것이 더 정확합니다.
David Winiecki

0

https://github.com/Mischback/django-project-skeleton 저장소 를 사용할 수 있습니다 .

아래 명령을 실행하십시오.

$ django-admin startproject --template=https://github.com/Mischback/django-project-skeleton/archive/development.zip [projectname]

구조는 다음과 같습니다.

[projectname]/                  <- project root
├── [projectname]/              <- Django root
   ├── __init__.py
   ├── settings/
      ├── common.py
      ├── development.py
      ├── i18n.py
      ├── __init__.py
      └── production.py
   ├── urls.py
   └── wsgi.py
├── apps/
   └── __init__.py
├── configs/
   ├── apache2_vhost.sample
   └── README
├── doc/
   ├── Makefile
   └── source/
       └── *snap*
├── manage.py
├── README.rst
├── run/
   ├── media/
      └── README
   ├── README
   └── static/
       └── README
├── static/
   └── README
└── templates/
    ├── base.html
    ├── core
       └── login.html
    └── README
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.