대형 Django 응용 프로그램 레이아웃

Question

저는 웹 기반 대학 포털을 개발중인 팀으로 Django를 기반으로합니다. 우리는 아직 탐색 단계에 있으며 프로젝트/개발 환경을 구축하는 가장 좋은 방법을 찾고 있습니다.

나의 초기 아이디어는 장고 "app"로 시스템을 개발하는 것이다. 여기에는 시스템의 다른 부분을 구분하는 하위 애플리케이션이 포함되어있다. 이 "하위"응용 프로그램을 만들려고 한 이유는 무엇이든 부모 응용 프로그램 외부에서 사용하지 않으므로 별도로 배포하는 것이 거의 필요하지 않기 때문입니다. 우리는 포털이 여러 위치 (예 : 다른 대학)에 설치되어 메인 앱을 여러 장고 프로젝트에 설치하여 설치할 수 있다고 생각합니다. 따라서 각 위치의 프로젝트마다 다른 저장소가 있습니다. 실제로는 설치된 포털 응용 프로그램을 정의하는 settings.py 파일과 URL을 urls.py으로 라우팅합니다.

초기 코드를 작성하기 시작했는데 문제가 발생했습니다. 사용자 인증 및 프로파일을 처리하는 코드 중 일부는 집이없는 것 같습니다. 개념적으로 포털 애플리케이션에 속하지 않습니다. 포털 애플리케이션의 기능과 관련이 없기 때문입니다. 그러나 프로젝트 저장소에 갈 수는 없습니다. 각 위치의 저장소를 통해 코드를 복제 할 것이기 때문입니다. 예를 들어이 코드에서 버그를 발견하면 모든 위치의 프로젝트 파일에 대해 수정 프로그램을 수동으로 복제해야합니다.

내 생각은 모든 프로젝트 repos를 "마스터"위치 프로젝트의 포크로 만들어 그 마스터에서 모든 변경 사항을 가져올 수 있도록하는 것입니다. 나는 이것이 지저분하다고 생각한다. 그리고 그것은 내가 볼 수있는 또 하나의 저장소가 있음을 의미한다.

이 프로젝트를 수행하는 더 좋은 방법을 찾고 있습니다. 누구든지 해결책이나 유사한 예를 추천 할 수 있습니까? 문제는 Django 프로젝트이 아닌 프로젝트 인 장고 을 개발하고있는 것 같습니다.

당신은 한 번 봐해야

Answer 1

내가 알아 낸 가장 좋은 방법은 응용 프로그램을 만든 다음 응용 프로그램을 만들어서 붙여 넣는 것입니다. 내 프로젝트의 대부분은 각각에 포함 된 유사한 애플 리케이션을 가지고 있습니다. 이메일, 메모, 작업 알림, 사용자 인증 등 선호하시는 레이아웃과 같이이다 :

• 프로젝트/
  • settings.py
  • urls.py
  • views.py
  • ...
• 애플 리케이션/
  • 이메일/
    • urls.py
    • views.py
    • ...
  • 노트/
    • urls.py
    • views.py
    • . ..
  • ...

애플리케이션하십시오 settings.py보다

은 "응용 프로그램"의 각 자체에 의미

및 기타 프로젝트 자체에 의존하지 않습니다 (그것은 비록 다른 앱에 의존 할 수 있음). 앱 중 하나는 사용자 인증 및 관리입니다. apps/auth/urls.py에 작업을 완료하기위한 모든 URL이 있습니다. 템플릿은 모두 apps/auth/templates/auth/입니다. 모든 기능은 자체 포함되어 있으므로 뭔가를 조정해야 할 때 어디로 가야하는지 알 수 있습니다.

프로젝트 :

project/ 최종 프로젝트에 함께 이러한 개별 응용 프로그램을 넣어하는 데 필요한 접착제를 제공합니다. 필자의 경우, project/에 settings.INSTALLED_APPS의 무거운 것을 사용하여 어떤 뷰를 볼 수 있었는지 구분할 수있었습니다.이런 식으로, 내가 INSTALLED_APPS에서 apps.notes을 가져 가면, 모든 메모가 여전히 훌륭하게 작동합니다.

유지 보수 :

이 레이아웃/방법론/계획도 장기적으로 긍정적 인 파급 효과를 가지고있다. 나중에 거의 모든 작업을 수행 할 수있어 나중에 다시 사용할 수 있습니다. 시스템을 아래에서 위로 테스트하여 전체에 통합되기 전에 각 응용 프로그램이 의도 한대로 작동하는지 확인하여 버그를 빨리 찾고 수정할 수 있습니다. 새 기능을 응용 프로그램의 기존 인스턴스로 롤아웃하지 않고 구현할 수 있습니다 (INSTALLED_APPS에 없으면 볼 수 없음).

프로젝트를보다 잘 문서화 할 수있는 방법과 더 널리 사용되는 방법이있을 것이라고 확신하지만, 지금까지 가장 잘 작동하는 방법이 있습니다.

Answer 2

: 당신은 재사용을 위해

GIT 또는 다른 CVS (자식이 관리하기에 좋습니다 + 배포를) 원하는 경우

• 장고 generic relations
• 장고 reusable apps 모범 사례를
• Fabric 당신이 필요로하는 경우
자동화 된 배포/업데이트

나는 보통이 프로젝트 구조를 사용 : 각 하위 응용 프로그램은 정적 서비스를 제공 할 수

• /djangoproject
  • /애플 리케이션
    • /주 # 주요 코드
    • /정적 #을
    • /app1
    • /statiC# 각 하위 앱은 통계를 제공 할 수 있습니다.
    • /app2 ...
  • /scripts # manage.py, wsgi, apache.conf, fabfile.py ...
  • /핵심 # 당신의 라이브러리 ...
  • settings.py
  • local_settings.py

에서/응용 프로그램 각각의 응용가 urls.py 이잖아 메인 urls.py에 autoincluded있다 . 그리고 각 응용 프로그램은 자식 서브 모듈 (또는 외부 svn)

또한 git을 사용하면 다른 병렬 분기 (master/dev/customerA/customerB ...)에서 작업하고 업데이트를 병합 할 수 있습니다.

장고를 사용하면 실제 재사용이 쉽지 않습니다.

Answer 3

당신은 별도의 모듈에 공통 기능을 추출하고 애플 리케이션에 의존 할 수 있습니다 :

• my_portal
• auth_module
• profiles_module
• 응용 프로그램 1을
• 응용 프로그램 2을 (auth_module에 따라 다름) (auth_module 및 profiles_module에 따라 다름)

나는 '고전적인'Django 프로젝트가 사용하고있는 앱을 '포함하는'것처럼 보이기 때문에 그림을 볼 수 없게된다고 생각합니다. 사실, 필요하지 않습니다. 일종의 플러그 가능한 모듈이있는 프로젝트의 경우, 앱을 알으로 구성하고 zc.buildout + djangorecipe를 사용하여 모든 것을 관리하는 것이 좋습니다.

이렇게하면 모듈을 평평한 1 레벨 구조로 유지할 수 있습니다. 계란에는 의존성을 지정할 수있는 기능이 있으므로 application1 (위 참조)을 설치하면 auth_module이 자동으로 설치됩니다.

다른 서버에 다른 구성을 배치하는 것도 쉬울 것입니다.

server1.cfg :

[buildout] 
extends = base_deployment.cfg 
eggs += application1 

server2.cfg :

[buildout] 
extends = base_seployment.cfg 
eggs += application1 
     application2 

- 설치 및 응용 프로그램 1 설치 응용 프로그램 2 모두있는 서버 2 응용 프로그램 1 한 서버 1가, 가정 당신은 단지 두 CONFIGS을 가질 수 있습니다

djangorecipe를 사용하면 각 빌드 아웃 구성마다 다른 설정 파일을 지정할 수 있으므로 기본 프로젝트의 URL과 설치된 앱 설정에 필요한 비트를 추가 할 수 있습니다.

물론 개발 구성을 위해 별도의 구성을 가질 수도 있습니다 (예 : debug = True 및 Django Debug Toolbar가 설치된 경우).