前提について
はじめまして、 プログラミングスクールに通ういりふねと申します。この記事は、スクールの課題である個人アプリの開発の記録を書くことで、自身のアウトプットに利用しています。もし、読んでいただけた方がいましたら、フィードバックをしていただけたら嬉しいです。
開発するのは「有給休暇管理ツール」です。仕様は過去記事をどうぞ。
アプリはデプロイまで行いますが、サービスとして提供するものではありません。あくまでも自学習の一環ですので、ご理解下さい。では本題へどうぞ。
今回の実施内容
前回までで有給休暇管理ツールのindex画面にあるリンクボタンには全てリンク先が設定できました。その後記事にはしていませんが、デプロイまで完了し、無事にスクールの発表会が終了しました。今回はデプロイ後にテーブルのカラムを追加し、再デプロイまでの流れを書きます。
- ローカルの編集
- 本番環境でのマイグレーション
- ビューの確認
開発環境
前提として開発環境を書くことを最近覚えました。
- Rails 5.2.4.2
- Ruby 2.5.1
- データベース postgreSQL
- デプロイ Heroku
ローカルでの編集
今回はHolidayテーブルに登録日を表す「registration_date」カラムを追加します。これまで有休の付与や消化のデータを取り出すためにデフォルトの「created_at」を使用していましたが、これを止めます。
理由は、先々の消化予定も入力できるようにしたいためです。このサイトで有給管理をする担当者を想定したときに従業員が有給を取る当日に合わせてデータ入力するのはやっぱり手間なので。
まずは、マイグレーションファイルをロールバックします。
$ rails db:rollback
マイグレーションファイルを編集します。
class CreateHolidays < ActiveRecord::Migration[5.2]
def change
create_table :holidays do |t|
t.date :registration_date, null: false
〜中略〜
end
end
再度マイグレーションを行います。
$ rails db:migrate
この他、モデルファイルに記述していた「created_at」を使用した日付の検索メソッドや有休登録画面に登録日のフォームを設置するなど必要な変更を加えていきます。複数ファイルの修正になるので、今回は割愛します。盲点だったのがコントローラーのストロングパラメーターへの追記忘れでした。created_atからの置き換えばかり意識していたので、すっかり忘れていました。何度か有休データが保存できずに焦りましたが、binding.pryを使用して原因を特定しました。
Herokuへのマイグレーション
変更したテーブルやビューを本番環境に反映させるためにHerokuから再デプロイをします。初めはHerokuからマニュアルデプロイでいいかなと思って実行しました。
しかしながら、エラーが!!（余談ですがこのエラー画面めっちゃ怖い。）
恐らく、テーブルに登録日カラムが反映されていないので、先程修正したビューファイルや日付検索メソッドたちがエラーとなっているのでしょう。
そこで、次はローカル環境と同じようにロールバックとマイグレーションを実行してみました。
$ heroku run rails db:rollback
結果の画面は以下のとおりです。少し見えにくいですが、「DROP TABLE "Holidays"」の記述があるので、どうやらロールバックは成功したようです。
続けて、同じ要領でマイグレーションも実行してみます。
$ heroku run rails db:migrate
こちらも結果は写真のとおりです。同じく見えにくいですが、「create_table(:holidays)」という記述と登録日カラムの「registration_date」が追加されていることが確認できました。
ビューの確認
本番環境でビューを確認します。新しいフォームの「登録日」が追加されていることが確認できます。フォームを追加したせいでビューが乱れています(泣)。今後ビューも手直しを入れる予定なので、その際に再度整えていきたいと思います。
次に登録後の消化履歴の画面です。こちらも問題なく表示されています。
今日の積み上げ
難航するかと思っていたテーブルのカラム追加ですが、思いの外、スムーズに終わりました。ただ、ロールバックを行うと本番環境であれ、レコードをは全てなくなったので、これが実際に提供されているサービスだと思うとゾッとします。
やはり、機能の洗い出しやデータベース設計は、めちゃくちゃ大切だということがわかりました。