Nous avons développé la première équipe de l'école de programmation que nous fréquentons. J'avais l'intention d'examiner en profondeur la conception de la base de données, mais je souhaite modifier les colonnes et réinitialiser la base de données de l'environnement de production pendant le développement! !! J'avais quelque chose à penser. Par conséquent, je conserverai un dossier comme mémoire. De plus, je pense que la réinitialisation de la base de données après le déploiement ne doit pas être effectuée. Pour ceux qui s'y réfèrent, n'oubliez pas que l'article a été écrit par un débutant en programmation.
AWS EC2 Déploiement automatique par Capistrano Capistrano Version: 3.14.0 (Rake Version: 13.0.1) Rails 5.2.4.3 ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin19] mysql Ver 14.14 Distrib 5.6.47, for osx10.15 (x86_64) using EditLine wrapper
[Rails] Une collection de commandes souvent utilisées dans le déploiement de l'environnement de production! Utilisation d'AWS / unicorn / nginx / Capistrano @ 15grmr Ajouter / supprimer des colonnes Ruby on Rails @azusanakano [Rails] Comment changer le type de données de colonne @yana_dev
--Modification des types de données de table et suppression et ajout de colonnes --Réinitialiser la base de données de production
En gros, cela correspond à l'ajout d'un fichier de migration. J'ai utilisé la méthode consistant à restaurer le fichier de migration, à le réécrire et à migrer à nouveau dans l'environnement local, mais cela ne semble pas très bon. Étant donné que le fichier de migration semble avoir un aspect de l'historique des modifications de table, la réécriture semble signifier que l'historique est falsifié. De plus, dans le développement d'équipe, si vous réécrivez la description de la migration sans autorisation, ... ① Non reflété dans les branches des autres membres (2) Des problèmes tels que la restauration du fichier de migration cible avant que d'autres membres ne fusionnent les branches (auquel cas, l'enregistrement de la base de données locale du membre de l'équipe peut être supprimé) se produisent également. Je vais.
Par conséquent, créez un fichier de migration pour les modifications de colonne afin de le gérer.
Cette fois, je vais prendre un exemple des modifications que j'ai réellement apportées. Parfois, je voulais changer le type de données de la colonne de préfixe dans la table des adresses de "chaîne" à "entier". Créez un fichier de migration avec la description suivante.
Terminal
$ rails g migration change_data_preficture_to_adresses
Décrivez dans le fichier de migration généré.
db/migrate/*****_change_data_preficture_to_addresses.rb
class ChangeDataPrefictureToAddresses < ActiveRecord::Migration[5.2]
def change
change_column :addresses, :preficture, :integer
end
end
Avec le déploiement automatique par Capistrano, il semble que la migration soit effectuée à chaque fois que le déploiement automatique est effectué, vous pouvez donc modifier le type de données de la colonne dans l'environnement de production.
Cela correspond également à la génération d'un fichier de migration. Utilisez deux fichiers, un pour supprimer des colonnes et un pour ajouter des colonnes. De même, dans mon exemple, le user_id dans la table cards a été créé avec une colonne de type entier normal au lieu d'une clé externe.
Commencez par supprimer la colonne user_id.
Terminal
$ rails g migration remove_user_id_from_cards
Décrivez dans le fichier de migration généré.
db/migrate/*****_remove_user_id_from_cards.rb
class RemoveUserIdFromCards < ActiveRecord::Migration[5.2]
def change
remove_column :cards, :user_id, :integer
end
end
Ensuite, générez un fichier de migration pour ajouter des colonnes. Cette fois, il s'agit d'une colonne de clé externe, donc la description est légèrement différente.
Terminal
$ rails g migration add_user_ref_to_cards
ref fait référence au type de référence de la clé externe.
python
class AddUserRefToCards < ActiveRecord::Migration[5.2]
def change
add_reference :cards, :user, foreign_key: true
end
end
Vous pouvez également supprimer et ajouter des colonnes en déployant automatiquement avec Capistrano.
Au milieu du développement, vous souhaiterez peut-être réinitialiser la base de données pour l'environnement de production. Je n'avais pas de compte pour l'environnement de production, et je ne pouvais pas me connecter, et par conséquent, je ne pouvais pas supprimer le produit précédemment enregistré (lien d'image cassé), et ainsi de suite.
J'ai donc réinitialisé la base de données dans l'environnement de production.
Terminal
$ bundle exec cap production deploy
Finissons le déploiement automatique par Capistrano une fois. Connectez-vous ensuite à AWS.
Terminal
$ ssh -i ~/.ssh/*******.pem [email protected]
Entrez le nom du fichier pem dans "*********" et l'adresse IP Elastic dans "XX.XXX.XXX.XX". Puis passez à "courant".
Terminal
$ cd /var/www/Nom de l'application/current
Si vous pouvez accéder à "courant", vous pouvez démarrer le fonctionnement de la base de données à partir d'ici. Tout d'abord, supprimez la base de données.
Terminal
$ RAILS_ENV=production DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop
Puisque la base de données pour l'environnement de production a disparu, je vais créer à nouveau la base de données.
Terminal
$ rake db:create RAILS_ENV=production
Effectuez la migration.
Terminal
$ rake db:migrate RAILS_ENV=production
S'il existe un fichier de départ, chargez-le.
Terminal
$ rake db:seed RAILS_ENV=production
Ceci termine la réinitialisation complète de la base de données. N'oubliez pas de vous déconnecter d'AWS.
Terminal
$ exit