Accueil / Blog / Métier / 2013 / Retour sur la Djangocong Belfort 2013

Retour sur la Djangocong Belfort 2013

Par Florent Lebreton publié 03/10/2013, édité le 11/11/2015
Comme à son habitude, Makina Corpus était sponsor de la Djangocong, organisée cette année à Belfort dans les locaux de l'UTBM. Une occasion d'apprendre plein de choses utiles et de partager un bon moment avec les djangonautes francophones.

Quelques retours d'expériences

La refonte de GreenBureau

Goulwenn Reboux a fait un intéressant retour d'expérience de la refonte de GreenBureau, un service de centralisation de relevés et factures.
Après un changement de législation, l'application est passée de quelques milliers d'utilisateurs à plus d'un million.
Pour supporter la charge, le choix a été fait de refondre l'infrastructure et de séparer de certaines technologies :

  • Suppression de Celery, MongoDB, Selenium server et du VPN;
  • Utilisation de Django seulement pour le core et remplacé par Flask pour le front.

En résultat, le gain de performances est important.
Le principal problème a été les grosses migrations de données.

La qualité et l'agilité chez Autolib

Le projet Autolib' devient conséquent (~ 500K lignes de code, 18 développeurs) et fonctionne 24h/24 7j/7 (qualité obligatoire donc).
L'équipe fonctionne en agilité :

  • Itérations très courtes :
    • mise en production le mardi, release le mercredi, mise en pré-production le jeudi;
    • relécture systématique de chaque release;
    • désignation d'un "build master" chaque semaine qui surveille : Jenkins, Sentry et Helpdesk;
    • avantage : la branche stable est toujours proche de la branche de développement (hotfixs plus faciles);
  • Organisation de l'équipe en trinomes :
    • 1 AMOA (en contact avec le client);
    • 2 développeurs (isolés des perturbations).
  • Rédaction de cahiers de tests (avec des scenarii priorisés);
  • Documentation systématique avec Sphinx (important pour un nouvel arrivant).

 

Quelques points techniques Django

Les formsets imbriqués

Samuel Goldszmidt a présenté le module nested-formsets de Nathan Yergler permettant de générer des formsets imbriqués pour éditer 2 niveaux de clés étrangères, tout en gardant la logique de gestion des forms et formets django.

Les transactions

Aymeric Augusin a fait un point sur le fonctionnement des transactions dans Postgresql et leur nouvelle gestion dans django 1.6.
À retenir notamment :

  • Avec psycopg2, la directive BEGIN (qui désactive l'autocommit) est insérée automatiquement avant chaque requête (même un SELECT), ce qui entraine une consommation de ressources inutile (car on ne commit pas manuellement après chaque requête ...). Il est tout de même possible de forcer l'autocommit via une variable de configuration;
  • Dans Django 1.6 :
    • Les requêtes SELECT/UPDATE/INSERT seront en autocommit par defaut, le passage à django 1.6 devrait donc améliorer les performances à ce niveau (cf problème psycopg2 ci-dessus);
    • ATOMIC_REQUESTS permet d'encapsuler toutes les requêtes SQL (d'une vue, pas des middlewares) d'une requête HTTP dans une transaction;
    • L'API atomic permet de gérer soit même les transactions :
      • via decorators et context_processors;
      • "commits on success" & "rolls back on exceptions";
      • Imbrication automatique de la transaction : une transaction est créée au premier appel de fonction et un savepoint est créé à chaque appel dans la call stack;
    • Les fonctions bas niveau existent toujours pour gérer tout manuellement dans le détail

.

Organisation du code

Plusieurs conférences ont eu des thèmes assez proches, autour de l'organisation du code, de la modularisation et de la séparation/abstraction des couches.

Eve Le Cellier et Charles Vallantin Dulac se rejoignent sur une idée largement partagée : il faut éviter toute logique métier et une trop lourde utilisation de l'ORM dans les vues (et à plus forte raison, dans les templates).
Deux pistes de solution sont envisageables :

  • Déplacer des requêtes dans les Manager et les Queryset (django-model-utils peut aider);
  • Ajouter une couche service.py ou api.py qui abstrait complètement les modèles (requêtage d'objets composés, réalisation d'opération complexe), en se rapprochant de l'utilisation du pattern Façade.

Quelques problèmes se dessinent :

  • Perte d'outils natifs de Django comme les model forms;
  • Duplication de code parfois difficiles à éviter (vérification des données entrantes par exemple).

Quelques posts de blog synthétisent bien les remarques et idées soulevées sur ces sujets :

Sur une thématique assez proche, Xavier Ordoquy conseille l'utilisation de modèles adaptables ("swappable models"), pour rendre l'utilisation des modules plus souples et améliorer leur adaptabilité dans le contexte de chaque application, à la manière ce que fait Django avec le customer user model.

Raphaël Barrois a pu faire plusieurs retours d'expérience sur l'intérêt de la modularisation (découplage des applications, utilisation des backends) et du packaging des libs (sic), qui facilitent les mises à jour sans interruption sur le projet Autolib'.

 

Un peu de tests

Deux lightning talks ont abordé un sujet indémodable : les tests !
Du premier, par Boris Feld, plutôt philosophique et méthodologique, on pourra retenir :

  • Se focaliser sur la logique (pas les getters et les setters), commencer par les scénarii vitaux et ne pas tester les autres bibliothèques;
  • Tester sur plusieurs niveaux (tests unitaires, tests d'intégration, tests fonctionnels);
  • Utiliser un outil d'integration continue (Jenkins pour les applications, Travis pour les modules);
  • Utiliser Mock pour bouchonner dans les environnements qu'on ne maitrise pas;
  • Pour aller plus loin, penser au TDD !

La jolie phrase reprise de Kent Benck motive et rassure : Tester, "c'est un moyen de gérer la peur pendant le développement".

Lors du second LT, plus pratique, Mathieu Agopian a présenté deux outils :

  • Pytest : pour les tests unitaires
    • deux packages à installer : pytest + pytest-django;
    • offre plein d'options "magiques" (sic) : statistiques sur les tests les plus lents, accès direct à une console pdb, ...;
    • le test runner est très souple.
  • Webtest : pour les tests fonctionnels
    • remplace le TestClient Django;
    • teste les statuts de réponses automatiquement;
    • facilite grandement la soumission de formulaires;
    • offre la possibilité de cliquer sur un lien présent dans la réponse;
    • permet de vérifier la structure du contenu avec pyquery.

 

Et aussi ...

On a aussi parlé d'e-commerce (django-oscar), de real-time web, et même de plantes suisses et de génotypage bactérien.

Pour finir, un peu de détente avec le très sympa lightning talk "Django WTF", inspiré de la célèbre conférence "WAT".

Merci aux organisateurs et à l'année prochaine, en PACA, dans un lieu tenu secret !

ABONNEZ-VOUS À LA NEWSLETTER !
Voir aussi
Formation Django initiation à Toulouse du 13 au 15 mars Formation Django initiation à Toulouse du 13 au 15 mars 26/01/2017

Entrez de plain-pied dans l'univers de Django aux côtés de développeurs ayant une expérience de ...

Retour sur la PyConFr 2016 Retour sur la PyConFr 2016 18/10/2016

Nous étions présents à Rennes pour PyConFr 2016. Voici notre compte-rendu à chaud.

Wagtail: How to use the Page model and its manager (part 2) Wagtail: How to use the Page model and its manager (part 2) 08/08/2016

The Page model has several methods specific to Wagtail. This is also the case of its manager. We ...

Wagtail : How to make your own content type models (part 1) Wagtail : How to make your own content type models (part 1) 29/07/2016

We are used to initialize our CMS directly from a web interface, often including lots of complex ...

Presentation of the latest Django CMS: Wagtail Presentation of the latest Django CMS: Wagtail 22/07/2016

Wagtail is a quite recent Django CMS. However, its young age does not keep it from having a lot of ...