Les "meilleures pratiques" sont très dépendantes du contexte, de sorte que je ne prétend pas que mes pratiques sont les meilleurs, juste qu'ils travaillent pour moi. Je travaille principalement sur les petits sites, donc pas de multiples déploiements de serveurs, de réseaux de diffusion de contenu, etc. J'ai besoin de soutien Webfaction d'hébergement partagé de déploiement, comme certains clients ont besoin le moins cher d'hébergement qu'ils peuvent trouver. Je fais souvent avoir à déployer des sites à plusieurs reprises dans des environnements différents, de manière reproductible script déploie sont essentiels.
- Je n'utilise pas de pip bundles, j'ai installer à partir d'une requirements.txt. Je fais mon propre chishop serveur avec sdists de tout ce dont j'ai besoin, donc il n'y a pas de multiples points de défaillance unique dans le processus de construction. J'utilise aussi PIP_DOWNLOAD_CACHE sur mes machines de développement pour accélérer l'amorçage des environnements de projet, puisque la plupart de mes projets les exigences de chevaucher un peu.
- J'ai le Tissu des scripts qui peut automatiquement configurer nginx + Apache/mod_wsgi sur une Ubuntu VPS, ou configurer l'équivalent sur Webfaction d'hébergement partagé, puis déployer le projet.
- Je n'utilisez pas l'option --no-site-packages avec virtualenv, parce que je préfère avoir à déplacement lent des paquets construits (Python Imaging Library, psycopg2) installé au niveau du système; trop lente et pénible à faire à l'intérieur de chaque virtualenv. Je n'ai pas eu d'ennuis avec système pollué site-packages, car en général je n'ai pas le polluer. Et dans tous les cas, vous pouvez installer une version différente de quelque chose dans le virtualenv et il aura la priorité.
- Chaque projet a son propre virtualenv. J'ai quelques scripts bash (pas virtualenvwrapper, même si beaucoup de gens l'utiliser et de l'amour) qui permettent d'automatiser le déploiement de la virtualenv pour un projet donné à un emplacement connu et l'installation de ce projet sur les exigences en elle.
- L'ensemble du processus de déploiement, à partir d'un nu Ubuntu serveur VPS ou Webfaction compte d'hébergement partagé pour l'exécution d'un site web, est codée à l'aide de Tissu.
- Tissu scripts font partie de la source du projet de l'arbre, et je les exécuter à partir d'un local de développement de la caisse.
- Je n'ai pas besoin de SCons (que je connais).
Déploiement
Actuellement, les frais de déploiement est divisé en les étapes suivantes:
-
fab staging bootstrap (et de configuration de serveur code initial déployer)
-
fab staging enable (activer Apache/nginx config pour ce site)
-
fab staging reload_server (reload Apache/nginx config).
Ceux-ci peuvent bien sûr être combinées en une seule ligne de commande fab staging bootstrap enable reload_server.
Une fois ces étapes effectuées, le déploiement de la mise à jour avec le nouveau code est juste fab staging deploy.
Si j'ai besoin de revenir un jour, fab staging rollback. Rien de magique dans la restauration; simplement, il restaure le code de la dernière version déployée et migre la base de données à l'état précédent (ce qui exige l'enregistrement des métadonnées à propos de la migration de l'état de la bd post-déploiement, je viens de le faire dans un fichier texte).
Exemples
Je n'ai pas utilisé le Tissu scripts décrits dans cette réponse, depuis quelques années, de sorte qu'ils ne sont pas maintenus à tous et je déclinons la responsabilité de leur qualité :-) Mais vous pouvez les voir à https://bitbucket.org/carljm/django-project-template - en fabfile.py dans les pensions de racine, et dans l' deploy/ sous-répertoire.
