Bonjour et bievenu :)
> Mon but final est de lancer "une commande" pour que ça termine en prod > en étant SUR que ça fonctionne (donc passage par une "preprod" > avec exceptions de tests). > J'ai jamais entendu parler de deploiement 100% automatique du style «Commit2Prod» peut être couplé à des tests A/B mais full push to prod automatique c'est... dangereux, nan ? Sinon pour le test automatique il y a Builtbot ou Jenkins j'ai essayé Jenkins je suis pas impresionné mais il peut faire ce que tu veux faire. Builtbot surement aussi. > Les questions seront volontairement vastes pour, j'espere, permettre une > plus grande liberté dans les réponses afin d'avoir un bel étendu de vos > habitudes : > > - Quel (D)VCS vous utilisez (svn, git, ...) ? > hg parce que c'est simple, git parce que ça donne l'air sociable avec github et ça fait l33t aussi. Il semblerai que les gens ai pas tous trop accroché au système des subrepositories (hg) et submodules (git) mais ça simplifie la vie du dev et le passage du dev à la prod en retirant les dépendances du requierements des trucs qui changes souvents (genre les app Django) et auxquelles tu dois souvent te référer pendant le dev (doc+code+grep ftw). Enfin sur mes derniers dev j'avais même Django en submodule mais parce que je faisait un dev vis à vis d'une beta du coup obligé d'avoir Django git, mais bon ça simplifie la vie même sur les dépôt d'appli ou quand tu dev des appli générique (c'est 2 ou 3 commandes à noter dans ton calpin ou fichier de recette fabric) > - Comment gérez vous les différences de configuration entre > dev/prod/whatever ? > Pas mieux que try/except dans le settings sans oublier de mettre une autre graine dans local_settings > - comment déployiez vous vos applis django en prod ? > En fait pour tout le process: - git push depuis le dev - git pull en preprod - clickouillage et test unitaires et autres - git pull depuis la prod si c'est bon - reload gunicorn (perso je kill et je relance dans un screen...) C'est en gros ce qui va dans une recette fabric, donc +1 Fabric et consort mais j'ai jamais utilisé donc je peux pas t'en dire plus c'est un système d'automatisation de ce que je sais. Bien sur ça deviens plus compliqué si tu as des changements de schema de base de donnée qui casse le code dans ce cas il faut mettre tout les serveur web hors ligne ou alors si tu as une replication au niveau de la db mettre hors ligne le maitre, l'update etc... mais t'auras pas le problème avec les bases de donnée en forme de graphe par exemple (toc!) Ainsi que les mises à jour de ces applis ? > C'est ce que j'ai oublié dans la liste en haut: pip install -r requirement.txt ou alors ça marche parce que c'est submodule et tu lance la commande qui va bien pour tout update correctement > Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien pour > ça que je demande vos avis. > ça dépend beaucoup de ton infrastructure/app en fait. > Si vous avez plus d'informations à partager que celles > demandées, n'hésitez surtout pas ! > A priori si c'est à usage interne donc relativement peu de traffic, ta configuration peut ressembler à: - nginx comme reverse proxy - 1 triplet (gunicorn + virtualenv + depot mercurial ou git) par projet Le tout dans une VM et une base de donnée bien sur qui peut être sur la même VM dans un premier temps après si tu as du temps et de l'argent tu peux tout séparer et faire des tuple (nginx, gunicorn, virtualenv, depot) mais je le ferais que pour scale dans le cas d'app interne. Sinon il y a sentry de pas mal à integrer à tes projets à mettre sur une VM séparé pour pouvoir avoir les log même en cas de plantage d'une VM serveur et à configurer en UDP.. South pour les migrations DB c'est ce kivabien(tm) Si tu suis la route git regarde git flow qui donne les pistes pour faire les choses bien(tm). Ainsi que Sphinx à maintenir à jour au moins pour l'installation du projet car c'est une sinécure sinon d’intégrer d'autre personne sur le projet. Je connais pas saltstake donc je ne saurais dire si c'est mieux ou pas. Bisoux PS: virtualenv c'est aussi controversationnel<http://pyrede.quiedeville.org/>(surement plus pour les git submodules) niveau sysadmin mais bon dans le cas ou t'a qu'une VM c'est difficille de faire autrement... PS2: tags et/ou branches bien sur
_______________________________________________ django mailing list [email protected] http://lists.afpy.org/mailman/listinfo/django
