[RUBY] [Development log ⑯] Heroku redeployment after table change

About the premise

Nice to meet you, my name is Irifune and I go to a programming school. This article is used for my own output by writing a record of the development of personal apps, which is a school task. If anyone has read it, I would be grateful if you could give us feedback.

We will develop a "paid leave management tool". For specifications, see Past Articles.

The app will be deployed, but it is not provided as a service. Please understand that this is just a part of self-study. Then go to the main subject.

Contents of this implementation

Up to the last time, all link destinations could be set for the link buttons on the index screen of the paid leave management tool. After that, I didn't write about it, but the deployment was completed and the school presentation was successfully completed. This time, I will add a column of the table after deployment and write the flow until redeployment.

--Local editing --Migration in production environment --View view

Development environment

I recently learned to write a development environment as a prerequisite.

• Rails 5.2.4.2
• Ruby 2.5.1 --Database postgreSQL --Deploy Heroku

Editing locally

This time, add a "registration_date" column to the Holiday table to represent the registration date. We used to use the default "created_at" to retrieve paid holiday granting and digestion data, but we will stop this. The reason is that I want to be able to enter the digestion schedule in the future. Assuming that the person in charge of paid management is on this site, it is troublesome to enter data according to the day when the employee takes paid leave.

First, roll back the migration file.

$ rails db:rollback

Edit the migration file.

models/*****_create_holidays.rb

class CreateHolidays < ActiveRecord::Migration[5.2]
  def change
    create_table :holidays do |t|
      t.date :registration_date, null: false
~ Omitted ~
  end
end

Migrate again.

$ rails db:migrate

In addition, we will make necessary changes such as a date search method using "created_at" described in the model file and a registration date form on the paid holiday registration screen. Since it will be a modification of multiple files, I will omit it this time. The blind spot was that I forgot to add to the strong parameters of the controller. I was conscious of replacing it with created_at, so I completely forgot. I was impatient because I couldn't save the paid holiday data several times, but I used binding.pry to identify the cause.

Migration to Heroku

Redeploy from Heroku to reflect the changed tables and views in your production environment. At first, I thought it would be okay to manually deploy from Heroku, so I ran it.

However, there is an error !! (As an aside, this error screen is really scary.)

Probably because the registration date column is not reflected in the table, the view file and date search method that I modified earlier are in error. So, next, I tried rolling back and migrating as in the local environment.

$ heroku run rails db:rollback

The result screen is as follows. It's a little hard to see, but it seems that the rollback was successful because there is a description of "DROP TABLE" Holidays "".

Next, try migrating in the same way.

$ heroku run rails db:migrate

The result is also shown in the photo. It's also hard to see, but I was able to confirm that the description "create_table (: holidays)" and the registration date column "registration_date" were added.

View view

Check the view in production. You can see that the "Registration Date" of the new form has been added. The view is messed up because I added the form (crying). We are planning to modify the view in the future, so I would like to arrange it again at that time.

Next is the digestion history screen after registration. This is also displayed without any problem.

Today's stack

I thought it would be difficult to add a column to the table, but it ended smoothly unexpectedly. However, when I roll back, even in the production environment, all the records are gone, so I'm horrified to think that this is the service actually provided. After all, it turned out that identifying functions and database design are extremely important.