ça peut être interessant en effet ça existe full auto http://engineering.quora.com/Continuous-Deployment-at-Quora
Le 30 mars 2013 03:08, Amirouche Boubekki <[email protected]> a écrit : > > 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
