Faire passer de Django 1.8 à Django 1.10 un projet de plus de 170K lignes !

L'un des derniers projet auquel j'ai participé consistait à faire la migration de Django 1.8 à Django 1.10 pour un vraiment gros projet Django. Cette conférence sera l'occasion de détailler notre cheminement et de revenir sur cette expérience au final assez amusante. Après tout, vous aussi vous allez peut-être vouloir migrer votre gros applicatif django 1.8 ?

Transcript

1. Faire passer de Django 1.8 à Django 1.10 un projet de plus de 150K 170K lignes !
2. Qui suis je ? Jean-Michel ARMAND aka @mrjmad Djangonaute.
3. Recueillir des indices Analyser la situation Trouver le coupable Un travail de détective Sautons à la conclusion Et dans tout les bons polars, il y a une voix Off, me voila !
4. Travail en binôme Hugo et votre serviteur En alternance Mais pourquoi ? Les enquêteurs Je suis sur que toute cette conf, c’est juste pour porter ce chapeau ridicule !
5. Rubber ducking Contrer le biais de confirmation Pouvoir se passer la main Pourquoi en binôme ? Et puis bon, niveau planning ce n’était pas possible autrement
6. Mais surtout !
7. Sherlock et Watson Starsky et Hutch Jennifer et Jonathan Hart Les grands détectives sont des binômes Ouaip, et puis Maigret et … sa pipe aussi !
8. L’objet du délit !
9. Projet django débuté en 2011 Plus de 170K ligne de python Des templates, tout tout plein Un pip-freeze de 135 lignes On migre quoi ?
10. Mode opératoire On est au slide 10, vous avez déjà survécu à la moitié !
11. 1.8 1.9 → Mise en production 1.9 1.10 → Il manque mise en production de la 1.10 dans le slide … rah la la Migration en 2 étapes
12. Développement en parallèle des migrations Petite difficulté en plus
13. Migrations des dépendances Grosse branche de travail Backportage maximum PR finale de migration 1.8 1.9 → 1.8 1.9 → Et voila que maintenant, il invente des mots..
14. Migrations des dépendances Branche de travail Backportage au plus tôt PR finale de migration 1.9 1.10 → 1.9 1.10 →
15. En mode au plus proche Incompatibilité des dépendances Gérer les changements fonctionnels -e git+ssh est votre ami Migration de dépendances
16. Les outils indispensables de l’enquêteur migrateur Les enquêteur migrateur, c’est ceux qui suivent les cigognes en hiver
17. Changelog des versions Code source de Django Code source des dépendances Les tests de votre application Une ligne directe vers l’équipe de dev La ligne directe, ce n’était pas un gros téléphone rouge … Dommage !
18. Vers 1.9 ! Vers l’infini et … au-delà !
19. Suppression du support de la notation pointée dans url() url(‘REGEX’, ‘core.bla.views’) url(‘REGEX’, core.bla.views) Seulement déprécié en 1.9 Ça n’est peut être rien pour vous, mais pour django ça veut dire beaucoup Changement url()
20. @override_settings reset de SETTINGS_MODULE https://code.djangoproject.com/ticket/25911 c’est ballot quand même, si jamais vous en aviez besoin !
21. Oubliez request.REQUEST[‘Key’] request.GET[‘K’] ou request.POST[‘K’] On est au slide 21, vous avez déjà survécu à la moitié !
22. django.utils.remove_tags() and removetags template filter https://code.djangoproject.com/ticket/23269 Suppression pour problème de sécurité
23. Imports de models trop tôt Tellement tellement de possibilités que ça plante
24. The add() method on a reverse foreign key now has a bulk parameter to allow executing one query regardless of the number of objects being added rather than one query per object. RelatedManager et add()
25. SURPRISE !!!! Nouvelle signature : add(*objs, bulk=True) Ancien comportement :add(*objs, bulk=False) RelatedManager et add() Vous pouvez ajouter ici la citation de James Doakes.
26. assertRedirect n’aime plus les URL absolues. On est au slide 26, vous avez déjà survécu à la moitié !
27. Avant : Model.objects.filter(related_id=RelatedModel.objects. all()) Maintenant : Model.objects.filter(related_id__in=RelatedModel.obj ects.all()) Le lookup __in n’est plus implicite
28. Vers 1.10 ! Toujours plus loin, toujours plus vite !
29. render(), les dict et les Context Heureusement on peut faire context_object.flatten() Changement dans render()
30. Select_related devient strict sur ce qu’on lui passe en paramètres On ne peut plus lui passer de champs non relationnels select_related() et consistance
31. On peut avoir des valeurs par défaut pour un champ On peut utiliser un callable pour calculer les valeurs par défaut MAIS !! Database, default et callable 1/2 On est au slide 31, vous avez déjà .. Ha Ha
32. On NE PEUT PLUS utiliser un callable qui utilise la base de données !! Contournement mis en place dans le save() du model Database, default et callable 2/2
33. Avant 1.10: if value is None: return None return bool(value) En 1.10 par contre : if value is None: return None return self.to_python(value) NullBooleanField et get_prep_value
34. Les TLD sont maintenant obligatoires Sinon vous avez une jolie ValidationError UrlValidator et tld
35. Changement de la notion de champ deferred Elle devient une notion dynamique
36. is_authenticated() et is_anonymous() deviennent des property ou des attributs ModelBackend d’authentification qui rejettent les utilisateurs inactifs render() des widgets change de signature (plus d’args choices) Petites joies des changements
37. En conclusion
38. Recueillir des indices Analyser la situation Trouver le coupable Un travail de détective Ce recyclage de slides, si ce n’est pas une honte !
39. Plus sérieusement
40. Tenez à jour vos standards de code Gérez vos dépendances, jour après jour Soignez vos tests Traquez les warnings django Pensez y, chaque matin en vous regardant dans la glace Une migration se prépare
41. Commencez tôt, en découpant les choses Ne bloquez pas toute l’équipe dessus Intégrez la migration dans le process de dev Stratégie Canari à mettre en place ? C’est comme pour les slides, on ne les écrit pas dans le train qui amène à la conf ! N’attendez pas le dernier moment
42. On ne migre pas entre deux phases de dev On dev entre deux phases de migrations ! Mais c’est quoi cette maxime toute pourrie ?
43. Merci Des questions ?