Open mfaure opened 2 years ago
Et ceci c'est cadeau 🎁
find db/migrate/ lib/tasks/deployment -exec basename '{}' \; | sort -n | awk 'BEGIN{ rev = -1 } /^[0-9]{14}_/ { prev=(curr || 0); curr=match($0, /.rb$/); if (prev == 0 && curr != 0) printf "--- v%d.0.0\n", rev += 1; print $0 }'
Le résultat obtenu est le même que dans l'exemple ci-dessus (qui avait été confectionné à la main avec amour)
Oh wow, bel example de awk 👌 Je suis partant pour mettre ça dans la doc de déploiement (en attendant d'avoir une meilleure solution technique pour les migrations N+X).
une solution non parfaite mais fonctionnant dans 99% des cas serait de créé des migrations qui appeleraient les after_party. Cela permettrait que la chronologie soit conservée entre les migrations et les after_party, tout en conservant la flexibilité des taches after_party
exemple un fichier /lib/tasks/deployment/20230322172910_populate_zones_with_tchap_hs.rake
namespace :after_party do
desc 'Deployment task: populate_zones_with_tchap_hs'
task populate_zones_with_tchap_hs: :environment do
[...]
AfterParty::TaskRecord
.create version: AfterParty::TaskRecorder.new(__FILE__).timestamp
end
end
et un fichier /db/migrate/20230322172910_populate_zones_with_tchap_hs.rb
class PopulateZonesWithTchapHs < ActiveRecord::Migration[6.1]
def change
Rake::Task['after_party:populate_zones_with_tchap_hs'].invoke
end
end
Merci @seb-by-ouidou pour cette proposition.
@tchak @LeSim @colinux @krichtof @mfo un avis ? pour info : @cmayran @Dan33l
Objet
L'objet de cette issue est de constituer le point de départ et lieu de discussion pour améliorer les migrations de donnée (et de schéma de base) lors de montée de tag. L'idée est de profiter de "l'expérience" Adullact, où nous avons fait une montée de tag de plus d'un an (!), non sans douleur :)
Actions
/cc @tchak @akarzim @jobygoude @kemenaran @krichtof
Ci-dessous se trouvent les notes du point sur le sujet du mercredi 16 février 2022
DS point migration de données (afterparty) 2022-02-16
Constat
Constat partagé : Dinum / Synbioz
Questions qui se posent :
1. Est-ce que le processus de mise à jour pourrait être mieux documenté ?
Aujourd'hui la base de code ne garantit que des mises à jour d'un tag N à N+1.
Est-ce qu'on pourrait :
2. Est-ce qu'after_party est une bonne manière de décrire les migrations de données ?
after_party n'est plus très actif depuis 2019. À voir si c'est un problème.
Cela dit, after_party n'est qu'un moyen de faire tourner des tâches de migration de données. On peut éventuellement trouver un meilleur moyen technique, mais reste que les tâches de migration de données existeront toujours.
3. Est-ce qu'on pourrait faire en sorte que les migrations N+X soient toujours possible ?
Est-ce qu'on pourrait écrire nos migrations de schéma et de données de sorte qu'il soit toujours possible de faire une mise à jour N+X ?
Pistes
Utiliser ActiveRecord pour les migrations de données
Mastodon fonctionne en mettant les migrations de données dans des migrations ActiveRecord - mais dans un dossier séparé (db/post_deploy au lieu de db/migrate).
Une mise à jour se passe typiquement comme ça :
SKIP_POST_DEPLOY_MIGRATIONS=true bin/rails db:migrate bin/rails server restart bin/rails db:migrate
L'idée est que :
(Implémentation : https://github.com/mastodon/mastodon/blob/c3aef491d66aec743a3a53e934a494f653745b61/config/initializers/0_post_deployment_migrations.rb#L1)
Tester automatiquement l'enchainement des migrations sur la CI
On peut écrire une action de CI qui teste automatiquement que les migrations de schéma et de données depuis un vieux tag de base fonctionnent correctement.
Exemple : https://github.com/mastodon/mastodon/pull/17393/files
Actions
README/doc/deploiement.md
qu'il faut, idéalement, ne faire que des montées de tag N+1Emplacement de la doc
/doc/deploiement.md
Exemple de montées de tag