Ich bin ein starker Befürworter der Versionskontrolle und fange an, an einem Django-Projekt zu arbeiten. Ich habe ein paar vorher schon einmal gemacht und ein paar verschiedene Ansätze ausprobiert, aber ich habe noch keine vernünftige Struktur gefunden, mit der ich mich wirklich wohl fühle.
Folgendes möchte ich:
a) Quellcode in Versionskontrolle eingecheckt
b) Vorzugsweise wird die Umgebung nicht in die Versionskontrolle eingecheckt (etwas wie buildout oder pip requirements.txt ist zum Einrichten der Umgebung in Ordnung)
c) Eine vernünftige "Erhalte einen neuen Entwickler" Geschichte
d) Eine sinnvolle Einsatzgeschichte - vorzugsweise könnte die gesamte Einsatzumgebung von einem Skript auf dem Server generiert werden.
Es scheint mir so, als ob jemand das schon einmal gemacht haben muss, aber viele Stunden der Suche haben zu halbfertigen Lösungen geführt, die nicht alle ansprechen.
Irgendwelche Gedanken, wo ich hinschauen sollte?
Ich habe ein Projekt / Verzeichnis in meinem Home-Verzeichnis (unter Linux). Wenn ich ein neues Projekt starten muss, mache ich ein neues, kurz genannt (das beschreibt das Projekt ausreichend) dir in projects /; das wird die Wurzel eines neuen virtualenv (mit --no-site-packages) für dieses Projekt.
Innerhalb dieses Verzeichnisses (nachdem ich das venv installiert, es bezogen und die Kopie von django installiert habe, mit der ich arbeiten werde), "starte ich" django-admin.py ein Unterverzeichnis, normalerweise mit demselben kurzen Namen . Dieses Verzeichnis wird zur Wurzel meines hg repo (mit einem schnellen hg init und ci), egal wie klein das Projekt ist.
Wenn es eine Chance gibt, das Projekt mit anderen Entwicklern zu teilen (z. B. ein Projekt für Arbeit), füge ich pip requirements.txt in den Repo-Stammordner ein. Nur Projektanforderungen gehen dort hinein; django-debug-toolbar und django-extensions, Grundbausteine für meinen Entwicklungsworkflow, sind beispielsweise keine Projektanforderungen. Südlich, wenn wir es benutzen, ist es.
Wie beim django-Projekt behalte ich normalerweise die Standardeinstellung settings.py, möglicherweise mit ein paar Änderungen, und füge die local_settings-Konvention am Ende hinzu ( try: from local_settings import *; except ImportError: pass ). Die spezifischen Umgebungseinstellungen meiner Entwickler und anderer Entwickler (zum Beispiel das Hinzufügen von django-extensions und django-debug-toolbar zu installierten Apps) gehen in local_settings.py, das nicht in die Versionskontrolle eingecheckt ist. Um einem neuen Entwickler zu helfen, könnten Sie eine Vorlage dieser Datei als local_settings.py.temp oder einen anderen Namen bereitstellen, der für keinen anderen Zweck verwendet wird, aber ich finde, dass dies den Repo unnötig stört.
Für persönliche Projekte schließe ich normalerweise eine README ein, wenn ich vorhabe, sie öffentlich zu veröffentlichen. Bei der Arbeit pflegen wir Trac-Umgebungen und gute Kommunikation, um neue Entwickler auf ein Projekt zu bringen.
Was die Bereitstellung anbelangt, wie ich bereits erwähnt habe, höre ich, dass Fabric für diese Art von automatisiertem Local / Remote-Scripting wirklich gut ist, obwohl ich nicht wirklich die Gelegenheit genutzt habe, mich damit zu befassen.
Für den Laien könnte eine typische Shell-Sitzung folgendermaßen aussehen:
%Vor%Sehen Sie sich die Struktur an, um Bereitstellungen zu verwalten.
Dies ist, was ich verwende, um Server / Bereitstellungen mit Fabric zu verwalten: louis (es ist nur eine Sammlung von Fabric-Befehlen). Ich behalte eine louisconf.py Datei mit jedem Projekt.
Ich würde empfehlen, ein verteiltes VCS (git, hg, ...) anstelle von svn zu verwenden. Der Grund dafür ist, dass die einfache Verzweigung mehrere Schemas für die Bereitstellung ermöglicht. Sie können beispielsweise production und staging Zweige haben. Dann erzwingst du, dass die einzigen Zusammenführungen in die Produktion von staging nach Konvention passieren.
Damit Entwickler schnell starten können, haben Sie es mit pip und requirements.txt richtig gemacht. Ich denke, das bedeutet auch, dass Sie virtualenv verwenden, aber wenn das nicht der dritte Teil ist. Ich würde empfehlen, eine grundlegende README an Ort und Stelle zu bekommen. Die erste Aufgabe jedes Entwicklers, der einem Projekt beitritt, besteht darin, die README zu aktualisieren.
Der grobe Weg, jemanden an Bord zu bekommen, ist, dass er den Code auscheckt, ein virtualenv erstellt und die Anforderungen installiert.
Ich würde empfehlen, eine settings.py -Datei zu haben, die mit sqlite3 zusammenarbeitet und die ein neuer Entwickler verwenden kann, um schnell loszulegen (dh nach der Installation der Anforderungen). Wie Sie die verschiedenen Einstellungsdateien verwalten, hängt jedoch vom Projektlayout ab. Es sollte jedoch einige Einstellungen für neue Entwickler geben.
Tags und Links django version-control deployment