【チーム開発】本日の進歩状況2020-07-17

【本日の作業】

・現在のmasterの内容を本番環境へマージし動くかどうかの確認。

明日はスプリントレビューとのことだったので、今日内に内容を本番環境にマージ、動作チェックを行いました。

いつも忘れそうなのでここで流れを整理

①サーバーにSSHでログイン

$ cd ~
$ cd .ssh/

で.sshディレクトリィに移動

$ ssh -i ダウンロードした鍵の名前.pem ec2-user@作成したEC2インスタンスと紐付けたElastic IP

でec2-userとしてログイン

②アプリケーションを設置しているディレクトリに移動しGithubの内容を本番環境へ反映

$ cd /var/www/[リポジトリ名]

で作業ディレクトリへ移動

$ git pull origin master

でローカルmasterの内容を本番環境へ反映

③念のためサーバーを停止→起動

まずUnicornのプロセスを確認

$ ps aux | grep unicorn

でUnicornのプロセスを確認

ec2-user 17877  0.4 18.1 588472 182840 ?       Sl   01:55   0:02 unicorn_rails master -c config/unicorn.rb -E production -D
ec2-user 17881  0.0 17.3 589088 175164 ?       Sl   01:55   0:00 unicorn_rails worker[0] -c config/unicorn.rb -E production -D
ec2-user 17911  0.0  0.2 110532  2180 pts/0    S+   02:05   0:00 grep --color=auto unicorn

master -cのec2-user後ろの数字がUnicornのプロセス本体のPID

$ kill <確認したunicorn rails masterのPID>

でUnicornのプロセスを停止

再度確認のため

[ec2-user@ip-〇〇〇-〇〇-〇〇-〇〇 <リポジトリ名>]$ ps aux | grep unicorn
...
ec2-user 17911  0.0  0.2 110532  2180 pts/0    S+   02:05   0:00 grep --color=auto unicorn

停止を確認したら

自分のローカルのターミナルのアプリケーションのディレクトリーで

$ bundle exec cap production deploy

で上手く動けば本番環境への自動デプロイは完了です。

今回はマイグレーションファイルをいろいろいじってたので、自動デプロイを実行する前にマイグレーションファイルのrollbackを行いました。

本番環境ではDBはとても大事なもの、（お客様とか商品情報とかいろいろ大事な情報が詰まっているもの）なのでローカルのように

$ rake db:migrate:reset

とか

$ rails db:rollback

とかでDBをリセットするのはできない仕様になっているようです。

それでも本番環境に適応しているマイグレーションファイルの中身を変えてしまった時は強制的に（擬似的に？）リセットする方法を行います。

[ec2-user@ip-〇〇〇-〇〇-〇〇-〇〇 <リポジトリ名>]
$ RAILS_ENV=production DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop

その後本番環境のディレクトリで

[ec2-user@ip-〇〇〇-〇〇-〇〇-〇〇 <リポジトリ名>]
$ rake db:create RAILS_ENV=production

$ rake db:migrate RAILS_ENV=production

$ rake db:seed RAILS_ENV=production

コマンドを入力しマイグレーションフィルのcreateとmigrate

ついでにseedファイルの実行でcategoriesテーブルの作成も行いました。

運営されているサイトでこんなことしたら打首もんなので開発期間中の裏技ですね。

でもこれに慣れてしまうと後々痛い目にあいそうなので程々にしたいと思います。

【躓いているところ】

言わずもがな画像投稿欄のJavaScript。

わかったようなわからないような。一進一退を繰り返しています。まだまだ先は長そうです。