Suggerimenti / Processo per lo sviluppo web utilizzando Django in una piccola squadra [chiusa]

Potrei fondamentalmente scrivere un piccolo libro sull'ottimizzazione del flusso di lavoro Django / Python, sia personalmente che in un ambiente di squadra. Proverò a elencare un paio di brevi punti:

• 1-5 va bene, questo è esattamente il punto che dovresti iniziare a partire da
• La comunità nel suo complesso si è completamente allontanata dal buildout per utilizzare il file dei requisiti associati a pip e pip
• Come complemento a pip, mantieni uno script bootstrap.sh nel tuo progetto che chiama setup.py , questo impacchetta ordinatamente l'intero progetto e rende l'installazione su un nuovo server estremamente semplice
• Cerca di utilizzare qualcosa come Jenkins per l'integrazione / test / distribuzione continua
• Per legare questo all'eccellente modello di ramificazione a cui sei collegato, puoi essenzialmente avere un controllo del post post-commit per le modifiche al tuo ramo master , e notifica a Jenkins che è tempo di costruire! (In alternativa, fai in modo che Jenkins effettui il polling del tuo repository git centrale ogni minuto, ecc.)
• In una build Jenkins di successo (tutti i test superati, indipendentemente dagli altri criteri che desideri) vengono distribuiti automaticamente sui server di staging (spero che tu abbia server di staging).
• Usa Fabric per il processo di distribuzione (allo staging e alla produzione allo stesso modo). Fabric è un wrapper di alto livello attorno ai comandi ssh / ftp / etc, tutto in Python, e rende i server di aggiornamento un gioco da ragazzi. Tutto ciò che faccio è digitare fab prod deploy e ogni singola macchina di produzione che possiedo viene completamente aggiornata automaticamente all'ultima versione del mio sito.
• Il monitoraggio dei server può essere eseguito utilizzando una combinazione salutare di Nagios, Graphite, Sentry (un'app di Django) e Overseer (un'altra app di Django)

Questo dovrebbe essere un buon punto di partenza. Se vuoi ulteriori consigli, consiglio vivamente di dare un'occhiata alle presentazioni fornite dagli sviluppatori su Disqus (la più grande app di Django al mondo). Probabilmente conoscono meglio l'ottimizzazione dei flussi di lavoro e del ridimensionamento rispetto a chiunque altro abbia mai incontrato.

Questa presentazione mostra una buona raccolta di strumenti / pratiche per il team python / django :

• Automated tests (Django built-in)
• Continuous integration (Jenkins, django-jenkins)
• Measure all the things (sentry, statsd + graphite, new relic)
• Scripted database (South)
• Scripted deployment (fabric)
• Configuration management (puppet/chef)
• Virtualised development (Vagrant)
• Test separation (test decorator, customise test runner)

A questo aggiungo:

• Usa pip per le tue dipendenze.
• Avere un gatekeeper per il tuo ramo principale in modo che nessun codice possa essere unito se non passa tutti i test.
• Si desidera eseguire i test il più spesso possibile durante lo sviluppo. Quindi, rendili il più veloce possibile (ad esempio usa sqlite per i test) o almeno dividili tra lento / veloce.

In realtà, non sono convinto che il modello di ramificazione sia utile per lavorare con Idiota. Una volta ero eccitato dal modello di ramificazione che assomigliava a quello che usavamo prima (CVSNT). Tuttavia, va (una sorta di) contro le idee Git. Rende le cose più complicate del necessario. Il punto di commit è più importante in Git di quanto lo sia il ramo . È più evidente se pensi a un ramo come al puntatore all'ultimo punto di commit nel ramo.

Ma potrebbe non essere la tua opinione. In ogni caso, puoi introdurre o abbandonare il modello di ramificazione in qualsiasi momento, in modo da poter iniziare con qualsiasi modello tu scelga e praticamente non perderai nulla.

Potrebbe essere una buona idea leggere il libro Pro Git di Scott Chacon, Capitolo 3. Git Branching.