Django-fr

Forum

#1 04-03-2013 21:05:40

bougie
Membre
Lieu : Rennes
Inscription : 04-03-2013
Messages : 2
Site Web

Workflow de développement et de d éploiement

Bonjour la liste smile

Pour commencer, rapide présentation vu que c'est mon premier mail !
Bougie, technicien/admin/esclave (surtout esclave ...) système dans une
SSII à Rennes. J'ai en charge le support des serveurs et/ou
le déploiement des nouvelles versions des applications metiers des (gros)
clients.
A coté, je fais du dev Django depuis quelques mois à titre perso (et dans
le cadre pro officieusement, mais uniquement pour mes "outils" à moi perso).

Voilà qui est fini pour la presentation smile

J'ouvre donc ce thread pour parler de vos methodes de développement, de la
gestion de vos sources et de la mise en prod.

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).
Mon coté admin va me faire créer des VMs á la volee pour installer
un environnement de tests propre et deployer l'application afin de la
tester.

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, ...) ?
- Comment gérez vous les differences de configuration entre
dev/prod/whatever ?
- comment déployiez vous vos applis django en prod ? Ainsi que les mises à
jour de ces applis ?

Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien pour ça
que je demande vos avis.

Si vous avez plus d'informations à partager que celles
demandées, n'hésitez surtout pas !

Au plaisir de vous lire wink

---------------------------
www.appartland.eu

Hors ligne

#2 04-03-2013 21:33:35

ksamuel
Modérateur
Inscription : 22-06-2012
Messages : 40
Site Web

Re : Workflow de développement et de d éploiement

Hello,

Personnement j'utilise Git.

Pour la différence de configuration, je m'assure d'homogénéiser au max
(même OS, matos similaire), sinon l'automatisation est un cauchemard.
Pour le gommage des différence, j'utilise un fichier de settings local
(une technique contreversée, mais qui a fait ses preuves) avec un try /
except ImportError à la fin du fichier de settings.

Enfin pour le déploiement, j'utilise des scripts fabric.


Le lun. 04 mars 2013 21:05:40 CET, David H. a écrit :
> Bonjour la liste smile
>
> Pour commencer, rapide présentation vu que c'est mon premier mail !
> Bougie, technicien/admin/esclave (surtout esclave ...) système dans
> une SSII à Rennes. J'ai en charge le support des serveurs et/ou
> le déploiement des nouvelles versions des applications metiers des
> (gros) clients.
> A coté, je fais du dev Django depuis quelques mois à titre perso (et
> dans le cadre pro officieusement, mais uniquement pour mes "outils" à
> moi perso).
>
> Voilà qui est fini pour la presentation smile
>
> J'ouvre donc ce thread pour parler de vos methodes
> de développement, de la gestion de vos sources et de la mise en prod.
>
> 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).
> Mon coté admin va me faire créer des VMs á la volee pour installer
> un environnement de tests propre et deployer l'application afin de la
> tester.
>
> 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, ...) ?
> - Comment gérez vous les differences de configuration entre
> dev/prod/whatever ?
> - comment déployiez vous vos applis django en prod ? Ainsi que les
> mises à jour de ces applis ?
>
> Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien
> pour ça que je demande vos avis.
>
> Si vous avez plus d'informations à partager que celles
> demandées, n'hésitez surtout pas !
>
> Au plaisir de vous lire wink
>
> ---------------------------
> www.appartland.eu <http://www.appartland.eu>
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

#3 05-03-2013 07:54:07

bougie
Membre
Lieu : Rennes
Inscription : 04-03-2013
Messages : 2
Site Web

Re : Workflow de développement et de d éploiement

Le 4 mars 2013 21:33, Kevin Samuel <kevsamuel _AT_ myopera.com> a écrit :

> Hello,
>
> Personnement j'utilise Git.
>
> Pour la différence de configuration, je m'assure d'homogénéiser au max
> (même OS, matos similaire), sinon l'automatisation est un cauchemard.
> Pour le gommage des différence, j'utilise un fichier de settings local
> (une technique contreversée, mais qui a fait ses preuves) avec un try /
> except ImportError à la fin du fichier de settings.
>
> Enfin pour le déploiement, j'utilise des scripts fabric.
>
>
> Le lun. 04 mars 2013 21:05:40 CET, David H. a écrit :
> > Bonjour la liste smile
> >
> > Pour commencer, rapide présentation vu que c'est mon premier mail !
> > Bougie, technicien/admin/esclave (surtout esclave ...) système dans
> > une SSII à Rennes. J'ai en charge le support des serveurs et/ou
> > le déploiement des nouvelles versions des applications metiers des
> > (gros) clients.
> > A coté, je fais du dev Django depuis quelques mois à titre perso (et
> > dans le cadre pro officieusement, mais uniquement pour mes "outils" à
> > moi perso).
> >
> > Voilà qui est fini pour la presentation smile
> >
> > J'ouvre donc ce thread pour parler de vos methodes
> > de développement, de la gestion de vos sources et de la mise en prod.
> >
> > 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).
> > Mon coté admin va me faire créer des VMs á la volee pour installer
> > un environnement de tests propre et deployer l'application afin de la
> > tester.
> >
> > 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, ...) ?
> > - Comment gérez vous les differences de configuration entre
> > dev/prod/whatever ?
> > - comment déployiez vous vos applis django en prod ? Ainsi que les
> > mises à jour de ces applis ?
> >
> > Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien
> > pour ça que je demande vos avis.
> >
> > Si vous avez plus d'informations à partager que celles
> > demandées, n'hésitez surtout pas !
> >
> > Au plaisir de vous lire wink
> >
> > ---------------------------
> > www.appartland.eu <http://www.appartland.eu>
> >
> >
> > _______________________________________________
> > django mailing list
> > django _AT_ lists.afpy.org
> > http://lists.afpy.org/mailman/listinfo/django
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>

Le 4 mars 2013 21:48, FoxMaSk <foxmask _AT_ gmail.com> a écrit :

Bonsoir,
> Pour la partie gestionnaire de versions, j'utilise Git (dans ma boite ils
> utilisent un truc de l'age "d'avant" la pierre : CVS)
> Je n'utilise pas django dans mon univers pro, juste à titre perso, ou
> alors sur des parties completement officieuses pour me permettre de
> faciliter mon admin oracle/jEE.
> Du coup pour les déploiements je ne suis pas un référant mais fabric
> semble etre "l'outil".
> Pour un projet open source en prod j'utilise des branch git et maintient à
> jour à coup de git pull et cela marche parfaitement sur ce modèle.
> Mais cela ne permet pas en une commande de passer vos sources en prod, il
> faut bien mettre à jour des fichiers de config et sa base de données.
> Pour les settings comme Kevin je fais un try except du local settings.

Hors ligne

#4 05-03-2013 08:12:20

Olivier
Membre
Inscription : 21-07-2016
Messages : 8

Re : Workflow de développement et de d éploiement

Bonjour
désolé pour le "bruit". J'avais répondu avec une mauvaise émail sur la ml.
D'où le copier coller de David wink
bonne journée
Le 5 mars 2013 07:56, "David H." <bougieskater _AT_ gmail.com> a écrit :

> Le 4 mars 2013 21:33, Kevin Samuel <kevsamuel _AT_ myopera.com> a écrit :
>
>> Hello,
>>
>> Personnement j'utilise Git.
>>
>> Pour la différence de configuration, je m'assure d'homogénéiser au max
>> (même OS, matos similaire), sinon l'automatisation est un cauchemard.
>> Pour le gommage des différence, j'utilise un fichier de settings local
>> (une technique contreversée, mais qui a fait ses preuves) avec un try /
>> except ImportError à la fin du fichier de settings.
>>
>> Enfin pour le déploiement, j'utilise des scripts fabric.
>>
>>
>> Le lun. 04 mars 2013 21:05:40 CET, David H. a écrit :
>> > Bonjour la liste smile
>> >
>> > Pour commencer, rapide présentation vu que c'est mon premier mail !
>> > Bougie, technicien/admin/esclave (surtout esclave ...) système dans
>> > une SSII à Rennes. J'ai en charge le support des serveurs et/ou
>> > le déploiement des nouvelles versions des applications metiers des
>> > (gros) clients.
>> > A coté, je fais du dev Django depuis quelques mois à titre perso (et
>> > dans le cadre pro officieusement, mais uniquement pour mes "outils" à
>> > moi perso).
>> >
>> > Voilà qui est fini pour la presentation smile
>> >
>> > J'ouvre donc ce thread pour parler de vos methodes
>> > de développement, de la gestion de vos sources et de la mise en prod.
>> >
>> > 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).
>> > Mon coté admin va me faire créer des VMs á la volee pour installer
>> > un environnement de tests propre et deployer l'application afin de la
>> > tester.
>> >
>> > 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, ...) ?
>> > - Comment gérez vous les differences de configuration entre
>> > dev/prod/whatever ?
>> > - comment déployiez vous vos applis django en prod ? Ainsi que les
>> > mises à jour de ces applis ?
>> >
>> > Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien
>> > pour ça que je demande vos avis.
>> >
>> > Si vous avez plus d'informations à partager que celles
>> > demandées, n'hésitez surtout pas !
>> >
>> > Au plaisir de vous lire wink
>> >
>> > ---------------------------
>> > www.appartland.eu <http://www.appartland.eu>
>> >
>> >
>> > _______________________________________________
>> > django mailing list
>> > django _AT_ lists.afpy.org
>> > http://lists.afpy.org/mailman/listinfo/django
>>
>>
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>>
>
> Le 4 mars 2013 21:48, FoxMaSk <foxmask _AT_ gmail.com> a écrit :
>
> Bonsoir,
>> Pour la partie gestionnaire de versions, j'utilise Git (dans ma boite ils
>> utilisent un truc de l'age "d'avant" la pierre : CVS)
>> Je n'utilise pas django dans mon univers pro, juste à titre perso, ou
>> alors sur des parties completement officieuses pour me permettre de
>> faciliter mon admin oracle/jEE.
>> Du coup pour les déploiements je ne suis pas un référant mais fabric
>> semble etre "l'outil".
>> Pour un projet open source en prod j'utilise des branch git et maintient
>> à jour à coup de git pull et cela marche parfaitement sur ce modèle.
>> Mais cela ne permet pas en une commande de passer vos sources en prod, il
>> faut bien mettre à jour des fichiers de config et sa base de données.
>> Pour les settings comme Kevin je fais un try except du local settings.
>
>
> --
> Site : www.appartland.eu
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>

Hors ligne

#5 07-03-2013 22:18:45

Stéphane Kanschine
Membre
Inscription : 21-07-2016
Messages : 2

Re : Workflow de développement et de d éploiement

Le lun.  4 mars, vers 21:05, David H. exprimait :

> Bonjour la liste smile

Salutations,

> 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, ...) ?

git, créer des branches pour la moindre feature/bug/... sans se
soucier du fait que le merge se fera.

> - Comment gérez vous les differences de configuration entre
> dev/prod/whatever ?

template dans un gestionnaire de configuration, saltstack pour ma
petite entreprise, puppet/capistrano dans une de mes missions
actuelles.

> - comment déployiez vous vos applis django en prod ? Ainsi que les mises à
> jour de ces applis ?

packaging debian, par habitude, sinon une tarball ou un pull à partir
d'un tag créer par git.

Numériquement,
Stéphane alias carxwol

Hors ligne

#6 30-03-2013 03:08:05

abki
Membre
Lieu : Paris
Inscription : 11-08-2010
Messages : 49
Site Web

Re : Workflow de développement et de d éploiement

Bonjour et bievenu smile



> 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

Hors ligne

#7 02-05-2013 21:48:05

abki
Membre
Lieu : Paris
Inscription : 11-08-2010
Messages : 49
Site Web

Re : Workflow de développement et de d éploiement

ç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 smile
>
>
>
>> 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
>

Hors ligne

#8 03-05-2013 07:28:46

yohann gabory
Membre
Inscription : 11-08-2010
Messages : 8

Re : Workflow de développement et de d éploiement

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 smile
>>
>>
>>
>>> 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
>

Hors ligne

#9 10-09-2013 15:04:45

olivier larcheveque
Membre
Inscription : 02-03-2011
Messages : 3

Re : Workflow de développement et de d éploiement

Bonjour,

Je rebondis sur tes interrogations car moi aussi je suis en
questionnement sur un changement de Workflow, je pense que ça peut
prendre sa place dans ton fil de discussions.

Présentement, j'ai une couple de projets Django déployés sur plusieurs
serveurs, et tous mes projets utilisent le pinning de versions pour les
dépendances dans des environnements virtuels.

Ce sont les tâches de mise à jour de certains paquets, commun à
plusieurs les projets, que je voudrais faire évoluer "plus
systématiquement" sans risque.
Typiquement, les updates de sécurité Django, il faut que je repasse dans
chaque projet...

Je pensais peut-être pour ce genre de paquet, à me réconcilier avec le
système et utiliser le packaging debian pour faire les updates. Mais ça
m'obligerait à retirer le pinning de version pour certains paquets, ce
que je trouve vraiment pas classe, mais ça me faciliterait la vie wink

J'aimerais ça avoir votre retour d'expérience là-dessus, et des conseils.

Merci.


Le 2013-03-04 15:05, David H. a écrit :
> Bonjour la liste smile
>
> Pour commencer, rapide présentation vu que c'est mon premier mail !
> Bougie, technicien/admin/esclave (surtout esclave ...) système dans
> une SSII à Rennes. J'ai en charge le support des serveurs et/ou
> le déploiement des nouvelles versions des applications metiers des
> (gros) clients.
> A coté, je fais du dev Django depuis quelques mois à titre perso (et
> dans le cadre pro officieusement, mais uniquement pour mes "outils" à
> moi perso).
>
> Voilà qui est fini pour la presentation smile
>
> J'ouvre donc ce thread pour parler de vos methodes
> de développement, de la gestion de vos sources et de la mise en prod.
>
> 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).
> Mon coté admin va me faire créer des VMs á la volee pour installer
> un environnement de tests propre et deployer l'application afin de la
> tester.
>
> 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, ...) ?
> - Comment gérez vous les differences de configuration entre
> dev/prod/whatever ?
> - comment déployiez vous vos applis django en prod ? Ainsi que les
> mises à jour de ces applis ?
>
> Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien
> pour ça que je demande vos avis.
>
> Si vous avez plus d'informations à partager que celles
> demandées, n'hésitez surtout pas !
>
> Au plaisir de vous lire wink
>
> ---------------------------
> www.appartland.eu <http://www.appartland.eu>
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

#10 10-09-2013 15:15:44

Rémy HUBSCHER
Membre
Inscription : 11-08-2010
Messages : 161

Re : Workflow de développement et de d éploiement

Bonjour,

Je vous invite à venir à Django Cong pour en discuter mais c'est un
sujet récurant qui a d'ailleurs été débattu à DjangoCon Europe cette année.

Il semble y avoir deux solutions intéressantes.

1/ Le provisioning des machines avec salt/chef/puppet (je vous conseille
personnellement salt) permet d'uniformiser les déploiements sur un parc
de machine avec des rôles.
2/ Utiliser un server pypi propre à la boite ou au projet avec les
versions des packets qu'on souhaite et releaser les packets logiciels
dessus. Ainsi un pip install -U -r requirements.txt fait le travail
(couplé avec salt toutes les machines se mettent seules à jour)
3/ Déploiement avec packet debian même chose que ci-dessus.

Il faut bien noter qu'il y a 2 choses : La configuration propre à chaque
projet et la version du code. Ce n'est pas tout à fait la même chose.
Le combo pypicache + salt semble être vraiment pas mal.

Sinon j'aime bien le couple salt + buildout car on a une meilleure
gestion des conflits de version dans les dépendances qu'avec pip et
mr.developer est vraiment génial pour gérer les dépôts privés.

Si vous venez à DjangoCong France à al fin du mois je vous promet un bar
camp là dessus. (http://rencontres.django-fr.org/)

++

Rémy



Le 10/09/2013 16:04, olivier larcheveque a écrit :
> Bonjour,
>
> Je rebondis sur tes interrogations car moi aussi je suis en
> questionnement sur un changement de Workflow, je pense que ça peut
> prendre sa place dans ton fil de discussions.
>
> Présentement, j'ai une couple de projets Django déployés sur plusieurs
> serveurs, et tous mes projets utilisent le pinning de versions pour
> les dépendances dans des environnements virtuels.
>
> Ce sont les tâches de mise à jour de certains paquets, commun à
> plusieurs les projets, que je voudrais faire évoluer "plus
> systématiquement" sans risque.
> Typiquement, les updates de sécurité Django, il faut que je repasse
> dans chaque projet...
>
> Je pensais peut-être pour ce genre de paquet, à me réconcilier avec le
> système et utiliser le packaging debian pour faire les updates. Mais
> ça m'obligerait à retirer le pinning de version pour certains paquets,
> ce que je trouve vraiment pas classe, mais ça me faciliterait la vie wink
>
> J'aimerais ça avoir votre retour d'expérience là-dessus, et des conseils.
>
> Merci.
>
>
> Le 2013-03-04 15:05, David H. a écrit :
>> Bonjour la liste smile
>>
>> Pour commencer, rapide présentation vu que c'est mon premier mail !
>> Bougie, technicien/admin/esclave (surtout esclave ...) système dans
>> une SSII à Rennes. J'ai en charge le support des serveurs et/ou
>> le déploiement des nouvelles versions des applications metiers des
>> (gros) clients.
>> A coté, je fais du dev Django depuis quelques mois à titre perso (et
>> dans le cadre pro officieusement, mais uniquement pour mes "outils" à
>> moi perso).
>>
>> Voilà qui est fini pour la presentation smile
>>
>> J'ouvre donc ce thread pour parler de vos methodes
>> de développement, de la gestion de vos sources et de la mise en prod.
>>
>> 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).
>> Mon coté admin va me faire créer des VMs á la volee pour installer
>> un environnement de tests propre et deployer l'application afin de la
>> tester.
>>
>> 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, ...) ?
>> - Comment gérez vous les differences de configuration entre
>> dev/prod/whatever ?
>> - comment déployiez vous vos applis django en prod ? Ainsi que les
>> mises à jour de ces applis ?
>>
>> Dans mon cas, je n'ai pas de réponses à ces question, et c'est bien
>> pour ça que je demande vos avis.
>>
>> Si vous avez plus d'informations à partager que celles
>> demandées, n'hésitez surtout pas !
>>
>> Au plaisir de vous lire wink
>>
>> ---------------------------
>> www.appartland.eu <http://www.appartland.eu>
>>
>>
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>
> --
> *Olivier Larchevêque*
> Développeur d'applications
> Agence universitaire de la Francophonie
> Téléphone IP : 00 1 1431
> Téléphone : +1 514 343 66 30 poste 1431
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

Pied de page des forums