[RUBY] About table changes and database resets after deployment

Introduction

We developed the first team at the programming school we attend. I intended to thoroughly consider the database design, but I want to change columns and reset the database in the production environment during development! !! I had something to think about. Therefore, I will keep a record as my memorandum. In addition, I think that resetting the database after deployment should not be done. For those who refer to it, please remember that the article was written by a programming beginner.

Development environment

AWS EC2 Automatic deployment with 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

Articles that I used as a reference

[Rails] A collection of commands often used in production environment deployment! Using AWS / unicorn / nginx / Capistrano @ 15grmr Add / Remove Ruby on Rails Columns @azusanakano [Rails] How to change column data type @yana_dev

What to write from now on

--Changing table data types and deleting and adding columns --Reset the production database

Change table data type and delete and add columns

Basically, it corresponds by adding a migration file. I've used the method of rolling back the migration file, rewriting it, and migrating again in the local environment, but this doesn't seem to be very good. Because the migration file seems to have an aspect of table change history, rewriting seems to mean that the history is falsified. Also, in team development, if you rewrite the migration description without permission, ... ① Not reflected in other members' branches (2) Problems such as having to roll back the target migration file before other members merge branches (in that case, the records in the team member's local database may be deleted) also occur. I will.

Therefore, create a migration file for column changes to handle it.

I want to change the CASE1 data type

This time, I'll take an example of the changes I actually made. Sometimes I wanted to change the data type of the prefix column in the addresses table from "string" to "integer". Create a migration file with the following description.

Terminal

$ rails g migration change_data_preficture_to_adresses

Describe in the generated migration file.

db/migrate/*****_change_data_preficture_to_addresses.rb

class ChangeDataPrefictureToAddresses < ActiveRecord::Migration[5.2]
  def change
    change_column :addresses, :preficture, :integer
  end
end

With automatic deployment by Capistrano, it seems that migrate is performed every time automatic deployment is performed, so you can change the data type of the column in the production environment.

I want to delete and add a CASE2 column

This also corresponds by generating a migration file. We will use two files, one for deleting columns and one for adding columns. Similarly, in my example, the user_id in the cards table was created with a normal integer type column instead of a foreign key.

First, delete the user_id column.

Terminal

$ rails g migration remove_user_id_from_cards

Describe in the generated migration file.

db/migrate/*****_remove_user_id_from_cards.rb

class RemoveUserIdFromCards < ActiveRecord::Migration[5.2]
  def change
    remove_column :cards, :user_id, :integer
  end
end

Next, generate a migration file for adding columns. This time it is a foreign key column, so the description is slightly different.

Terminal

$ rails g migration add_user_ref_to_cards

ref refers to the reference type of the foreign key.

python

class AddUserRefToCards < ActiveRecord::Migration[5.2]
  def change
    add_reference :cards, :user, foreign_key: true
  end
end

You can also remove and add columns by auto-deploying with Capistrano.

I want to reset the database in the production environment

You may want to reset the production database during development. I didn't have an account for the production environment, and I couldn't log in, and as a result, I couldn't delete the previously registered (broken image link) product, and so on.

So I reset the database in the production environment.

Terminal

$ bundle exec cap production deploy

Let's finish the automatic deployment by Capistrano once. Then log in to AWS.

Terminal

$ ssh -i ~/.ssh/*******.pem [email protected]

Enter the name of the pem file in "******" and the Elastic IP in "XX.XXX.XXX.XX". Then move to "current".

Terminal

$ cd  /var/www/Application name/current

If you can access "current", you can start database operation from here. First, drop the database.

Terminal

$ RAILS_ENV=production DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop

Since the database for the production environment is gone, I will create the database again.

Terminal

$ rake db:create RAILS_ENV=production

Perform migration.

Terminal

$ rake db:migrate RAILS_ENV=production

If you have a seeds file, load it.

Terminal

$ rake db:seed RAILS_ENV=production

This completes the complete database reset. Don't forget to log out of AWS.

Terminal

$ exit