15-10-2018, 07:35 PM
(Modification du message : 15-10-2018, 07:35 PM par Sephi-Chan.)
Le plus simple c'est de prévoir ce downtime et arrêter le site pour maintenance.
Quand au nombre de migrations, j'ai travaillé sur beaucoup d'app Rails avec des centaines de migrations et ça n'a jamais posé problème, à moins que quelqu'un ne modifie la BDD de production a la mano entre temps, chose improbable.
Tu les génères via une ligne de commande, genre :
Ça te génère un fichier du type db/migrate/YYYYMMDDHHMMSS_add_info_to_users.rb
La plupart des migrations sont automatiquement réversibles (même de bien plus compliquées). Si tu migres les données, c'est bien sûr à toi de le faire.
Les outils de déploiement automatiques (Mina, Capistrano) déploient via le SCM (généralement Git) et ont une fonction de rollback qui remet les anciennes sources et relance les scripts de rollback.
Quand au nombre de migrations, j'ai travaillé sur beaucoup d'app Rails avec des centaines de migrations et ça n'a jamais posé problème, à moins que quelqu'un ne modifie la BDD de production a la mano entre temps, chose improbable.
Tu les génères via une ligne de commande, genre :
rails generate migration AddInfoToUsers name level:intÇa te génère un fichier du type db/migrate/YYYYMMDDHHMMSS_add_info_to_users.rb
class AddInfoToUsers < ActiveRecord::Migration
def change
add_column :users, :name, 
tring
add_column :users, :level, :integer
end
end
La plupart des migrations sont automatiquement réversibles (même de bien plus compliquées). Si tu migres les données, c'est bien sûr à toi de le faire.
Les outils de déploiement automatiques (Mina, Capistrano) déploient via le SCM (généralement Git) et ont une fonction de rollback qui remet les anciennes sources et relance les scripts de rollback.