Testing migrations FR

Transcript

1. TESTING MIGRATIONS https://github.com/jrobichaud/django-awesome-presentations
2. TESTING MIGRATIONS QU’EST CE QU’UNE MIGRATION ▸ Les migrations sont la manière par laquelle Django propage des modifications que vous apportez à des modèles (ajout d’un champ, suppression d’un modèle, etc.) dans un schéma de base de données. ▸ Elles sont conçues pour être quasiment automatiques, mais vous aurez besoin de savoir quand créer les migrations, quand les exécuter, et les problèmes courants que vous pourriez rencontrer. ▸ L’équivalent existe dans Ruby on Rails et dans Laravel
3. TESTING MIGRATIONS EXEMPLE DE MIGRATION # Generated by Django 2.0.1 on 2018-01-12 01:13 from django.db import migrations, models class Migration(migrations.Migration): initial = True dependencies = [ ] operations = [ migrations.CreateModel( name='AwesomeModel', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('name', models.CharField(max_length=100)), ], ), ]
4. TESTING MIGRATIONS CUSTOM MIGRATION from django.db import migrations def migrate(apps, schema_editor): kitten_model = apps.get_model('testing_migrations', 'Kitten') kitten_name_model = apps.get_model('testing_migrations', 'KittenName') for kitten in kitten_model.objects.all(): kitten_name_model.objects.create( kitten=kitten, name=kitten.name, ) def migrate_reverse(apps, schema_editor): kitten_model = apps.get_model('testing_migrations', 'Kitten') for kitten in kitten_model.objects.all(): kitten.name = kitten.kittenname_set.first().name kitten.save() class Migration(migrations.Migration): dependencies = [ ('testing_migrations', '0004_kittenname'), ] operations = [ migrations.RunPython(migrate, reverse_code=migrate_reverse) ]
5. TESTING MIGRATIONS COMMANDES DE BASE ▸ python manage.py makemigrations ▸ python manage.py migrate ▸ python manage.py makemigrations —merge
6. POURQUOI TESTER LES MIGRATIONS?
7. POURQUOI TESTER LES MIGRATIONS? CONSÉQUENCES GRAVES ▸ Risques de corruption de données ▸ Pertes de données si rollback ▸ Downtime ▸ Conséquences monétaires (SLA) ▸ Perte de confiance ▸ Perte d’estime de soi
8. POURQUOI TESTER LES MIGRATIONS? PLUSIEURS AVANTAGES ▸ Réduire les risques ▸ Aide au peer-review ▸ Facilite les optimisations du temps de migration ▸ Permet de tester les “reverse migrations” ▸ Coverage ▸ S’assure que les migrations vont continuer de fonctionner jusqu’au moment de l’exécution
9. POURQUOI TESTER LES MIGRATIONS? SOURCES COMMUNES DE PROBLÈMES ▸ Mauvaise gestion de l’ordre d’exécution des migrations ▸ Cas non gérés ▸ Méthodes des modèles “clean/save” non appelées ▸ Mauvaise gestion des transactions ▸ Paradox spatio-temporel ?!?
10. <THE MIGRATION> COULD CREATE A TIME PARADOX, THE RESULTS OF WHICH COULD CAUSE A CHAIN REACTION THAT WOULD UNRAVEL THE VERY FABRIC OF THE SPACE TIME CONTINUUM, AND DESTROY THE ENTIRE UNIVERSE! GRANTED, THAT'S A WORSE CASE SCENARIO. THE DESTRUCTION MIGHT IN FACT BE VERY LOCALIZED, LIMITED TO MERELY OUR OWN GALAXY. PARADOX SPATIO-TEMPOREL ?!?
11. Migration
12. PARADOX SPATIO-TEMPOREL ?!? COMMENT LES ÉVITER? ▸ Ne pas utiliser tout ce qui va changer (Ex: fonction helper qui va changer après la migration) from foo import bar bar(instance) ▸ Éviter d’utiliser ce qui pourrait changer ▸ fixtures ▸ Avoir des tests qui roulent en tout temps jusqu’au déploiement
13. DEMO
14. RÉSUMÉ BONNES PRATIQUES ▸ Tout de même faire des tests avec des vraies données ▸ Échouer tôt ▸ Implémenter et tester les reverse migrations ▸ Créer une bulle spatio-temporelle ▸ Enlever les migrations custom ainsi que leurs tests après toutes les migrations des serveurs ▸ Squash migrations