[afpy/django] Workflow de développement et de déploiement

boblefrag boblefrag at gmail.com
Ven 3 Mai 08:28:46 CEST 2013


Bonjour la liste.

Personnellement, j'utilise git dans ma boite, hg a titre perso.
pour le déploiement, j'utilise jenkins et fabric.

Les settings
----------------

Au niveau des settings, j'utilise l'astuce suivante (local_settings.py
c'est mal)
- un fichier settings de base dans lequel je met tout ce qui ne changera
pas quelque soit l'environnement.
- un fichier ***_settings.py par environnement
soit :
- ci_settings.py pour jenkins
- devel_settings.py pour moi même
- preprod_settings.py pour la préprod
- prod_settings.py pour la prod.

tous ces settings sont versionnés.

A la fin de mon fichier settings.py j'ai :

from local_settings.py import *

Le fichier local_settings.py qui lui n'est pas versionné ne contiens que :

from ***_settings.py import *

En fonction de l'environnement donc.

Pour la secret_key, les clé d'API etc, j'utilse des variables
d'environnement.

Intégration Continue
----------------------------

Si tu veux automatiser la mise en prod, c'est juste obligatoire.

j'ai un petit script dans jenkins qui va init un virtualenv, installer les
requirement.txt et lancer mes tests en utilisant django_jenkins

J'utilise coverage et pylint.

Si la couverture de test est suffisante et que les tests passent, jenkins
va placer le build en "promoted build" et lancer un script shell.

Déploiement
------------------

Ce script shell va consister à lancer deux commandes fabric que j'ai
écrites :

-  deploy

qui fait un
- git pull
- python manage.py syncdb --noinput
- python manage.py south migrate
- python manage.py collectstatic --noinput
….

Bref tout ce qu'il faut pour mettre le projet à jour.

- restart_server

Qui va tout simplement relancer mon process uwsgi

Mise en prod
------------------

Pour le moment je ne suis pas assez courageux/fou (rayez la mention
inutile) pour mettre en prod dans la foulée. La pré-prod sert à faire
quelques tests d'intégration manuels, clicouillages etc…

Quand je veux passer en prod je lance donc mon fab deploy restart_server
sur la prod et roulez jeunesse.






Le 2 mai 2013 22:48, Amirouche Boubekki <amirouche.boubekki at gmail.com> a
écrit :

> ç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 <amirouche.boubekki at gmail.com>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
> django at lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.afpy.org/pipermail/django/attachments/20130503/5ff424f4/attachment-0001.html>


Plus d'informations sur la liste de diffusion django