ねこものがたり

いちにちいっぽ

Rails.envにstagingを追加するのはよくないと言われるのは何故か整理してみました

このエントリのきっかけ

業務で開発してるRailsアプリケーションにRails.envがたくさんあって、「環境を整理したい」「デフォルトに寄せたい」という話が沸いています。 「それはそう」って思ってしばらく過ごしていたんですが、あるときふと「何故?」って聞かれたら自分は説明できないな、と気付いたので、これを機によく理解しておこうと思いました。 この記事は"備忘録"と言うやつですね!(私の場合備忘録じゃないブログエントリほとんどないですが)

デフォルトのRails.env

デフォルトとRails.envはdevelopment, test, productionです。rails new したらこの3つの環境が備わっています。 それぞれどう言うものかという詳細は productionやdevelopment、stagingという言葉の使い分けについて|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社がまとまっていてわかりやすいと思いました。

productionモード
本番モードで、動作中にソースコードが編集されない前提が取れるため、クラスキャッシュなどをアグレッシブに保持して効率化ができる(config.cache_classesやconfig.eager_load)
静的ファイル配信はRailsサーバーからではなくnginxなどの手前Webサーバーから配信させる前提の設定(config.public_file_server.enabled = false)がされている

developmentモード
起動中にソースコードが編集されてもRailsサーバーの再起動不要で変更結果が反映される(config.file_watcherやconfig.cache_classesの無効化など)
開発者のローカル環境ではいちいちnginxなどを立ち上げなくても良いように、public以下の静的ファイルもRailsサーバーが配信する(config.public_file_server.enabled = true)

testモード
developmentモードに近いが、さらにCIやターミナル前提の設定などが付く(consider_all_requests_local = :stderr)

新しい環境を作る方法

Rails アプリケーションを設定する - Railsガイド

config/environments/staging.rb を作ればstagingができます。 staging.rbの中には必要な設定項目を記載します。

stagingを作らない方がいい理由

Rails が標準として環境追加の機能を備えているのに、どうして「それはダメです」と言う声が多いんだろう? ここから先は私が調べたり、現場で体感したりしたことのまとめです。

そもそもステージング環境とはなんだ

「検証環境」と言う言葉でさもそれらしい認識はしていた私ですが「ちゃんと説明して」と自問してみるとどうやら理解が浅いぞと気付いたので調べてみました。

ステージング環境 (staging environment)がとってもわかりやすかったので拝借します。

できるだけ実際に使うときの状況(本番環境)に似せて作った動作確認用の場所(テスト環境)のこと

できるだけ実際に使うときの状況(本番環境)に似せていると言うのがstagingのポイントのようです。

config/environments/staging.rb でステージング環境を作成するデメリット

上述のように config/environments/staging.rb を config/environments/production.rb と同じ設定内容で作成すると名前は別だけれど設定は同じになります。 では何故ダメなのか?内容同じにすれば本番環境と同じになるならよくない?という気も(ほんの少し)してきました。

でも長期的な運用を考えたときに「設定内容の同期が不確実」と言う懸念点が挙げられます それはつまり、production.rbを変更をしたときstaging.rbも変更しないといけない(逆もまた然り)で、「本当にこの環境は十分本番に似せ切れているのか?」を担保し切れなくなってしまうかもしれません。 本番にリリースして問題ないか確認するためのステージング環境なのに前提が崩れてしまう可能性をはらんでいます。

どのようにステージング環境を用意すると良いか

思い切って(?)ステージング環境もconfig/environments/production.rbを使いましょう。 でもconfig/environments/staging.rbをそのまま使っているだけではそれはただの本番環境なのでステージングになりません。 どうすれば??

本番とステージングで環境で同じにするもの・差分が必要なもの

どうすればいいんだろう整理する為に、何を使い分けると良いのか考えてみると以下のようになるのかなと理解しています。

同じにするもの:基本的に全て

変えるもの:本番と同じにしてはいけない値

本番環境と同じであることを基本として、本番と同じものは使えない値だけを変えると良いようです。 アプリケーション全体で言うとDBの接続先を本番用じゃないDBにする等、config/environments/production.rbファイル以外のconfigの値の方が注意を払わないといけない対象が多いように思います。

config/environments/production.rbを共有しながら値を使い分ける方法

production.rbの設定値を環境変数の参照にすると良さそうです。 rails sに何かフラグを渡せるようにして、それによって参照先も変える方法があります。

まとめ

stagingを追加するのがよくない理由は、要するに本番環境同等の環境の担保の問題だと理解しました。

この記事を書いていて、production.rbの設定でステージング環境も動かすためにも、秘匿情報やAPIやDBの参照先、何かの通知設定など本番と同じにしてないけないこと・分けておきたいことは何かを整理して事故のない運用と品質の担保をしていきたいと思いました。

Kaigi on Rails STAY HOME Editionに参加しました

イベントページ

kaigionrails.org

デザイン可愛いー

セッションの感想

全部書きたいのだが息切れしてしまったので一部のみ😢

『Viewがレンダリングされるまでの技術とその理解』:Aaron Patterson

なんだかすごい人ってカッコ良くて眩しくて雲の上の存在で「うわっ」って思いがちな自分なんですけれども、そんなことを考えずに「やってみたい」って思う内容でした。「Rails全体の話をしたいけど時間も限られているのでViewのレンダリングを」という経緯でのお話だったのですが、特に、Routingが木構造でパースして一致しているアクションを探して...という流れの話のあたりにすごくときめきました。

少し前にアルゴリズムとデータ構造の勉強を始めて、いきなりハイレベルなコンテンツを選んでしまった為に挫けていたんですが、簡単なところから構造の理解をちゃんとしたいっていう気持ちが高まってきました。 routingを自分で書いてみたいな。

育てるSinatra:onk

Sinatraってちょろっと触ったことがあるんですが(なんでだったかなー面白そうだったからな気がする)けど、それをRails風にしてみようという発想がまず新鮮に感じました。上述のアーロンさんの話がイベントの一番最初の話だったので、その話の余韻を胸にこの話を聞くと、「うわ、これはやりたい」とときめきがブーストされましたw なお、当日ご本人はISUCON本戦に出場されていたそうで。カッコ良すぎる不在理由。

まったく余談だけど、アーロンさんもonkさんも落ち着いた声で聞きやすいので発表いつも引き込まれます。あれはなんなんだろう。

継承とメタプログラミング満載なアプリケーションコードでもアクションとフィルタに悩まないためのGemを作った話:makicamel

github.com

こちらのgemを作った話。makiさんとはいつも仲良くさせてもらっている(出会ったのは1年前とかなんだけれどプログラミング仲間で今一番繋がりが強いのは彼女だと思う)ので、プロポーザル出す前からこういう話をしたいというのは聞いていて、登壇が決まったのでとても楽しみで、「できた!」と聞いてとても嬉しくて。当日の発表ももちろんなんですけれど、経緯をそばでみていて知っているのでなお尊敬と称賛とねぎらいの気持ちでいっぱいです。

このgemは私もお仕事で使っていこうと思っています。

Railsワンマン運転の手引き:ベーた

べーたさんってそういえばなんでベーたなんだっけ(いつか聞いた気はする)。ベーたさんはRails Girlsがきっかけで知り合って、とても明るくて難しい話をわかりやすく説明するのがお上手な方だなという印象を抱いていました。今回の話もわかりやすかったです!

お仕事で一人開発はしたことがないのだけど、やっぱりRailsそのものよりその周辺の知識をわかっていくのって全部が全部すんなりというわけではなくて「概念が難しい!」と思うことが多いのだけど、入口がべーたさんのこの話だったらスッと、考え方や目的が頭に入って良さそうです。 igaigaさんの 『RubyRails の学習ガイド』(参考:https://techbookfest.org/event/tbf06/circle/56370001)もセットにすると周辺には何があって何の理解が必要か全体像がわかってすごく良さそうに思いました。 私はわかっていないことが多いので、振り返りたいと思います。

快適なリモートワークを実現するために〜RailsでSSOを実現する3パターン :下重 博資

これめちゃくちゃよかったです。いますぐ会社にこれをこのまま導入したい!!!!!それくらい参考になる話だったのですが、そもそもの「リモートワークでこういう点を不便に感じた」「セキュリティーが心配」という点を技術で解決しているという着眼点も気づきも発想も取り組みも最高でした。一度話を聞くと、またこうして言葉にすると、「技術屋なんだから技術で解決するのは当たり前じゃん?」って思う方もおられると思うのですが、私自身がもっとそういう点でハングリーでありたいと試みているフェーズなので、刺さるものが多かったです。

coming soon :Akira Matsuda

OSSやろう!みたいな話でした。(ざっくり) これは自意識過剰と自覚した上で認めるのですが、「あ!私宛の話だ!」とすごく思いました。と言っても話の内容が「参考になる!」とかそんなふうに思ったかというと、思ったんですが違う気持ちをより強く抱きました。 自分は「やっていきたいけどできる気がしない」「世の中には難しいことが多すぎる」と、まあつまり簡単に諦めちゃうところがあります。でも、勝手に物事のハードルをあげている自分や、自分を下げている自分がいるという、自分の内面をはっきり自覚して、「これは自分のスキルじゃなくてメンタルの問題」とはっきりと思いました。”はっきり”と繰り返したのは、前から少しは思っていたんですが、「そんな風に思う自分はダメだ」と半ば蓋をして、みないフリをしてきたからです。強がったらいいのかなって。でもそういう見栄を張るのは無駄なのでやめて、自分のそういう弱いところははっきり認めて変えていこうというのを思いました。OSSやろうという話だったけれどOSS云々の前に、そんな自分にチャレンジしていこう、と最後の基調講演で決意しました。

その他

Rubyで書かれたソースコードを読む技術』を発表されたfukajunさんとソースコード読んでいきたいけど難しすぎると挫けがちという悩み相談を抱えて懇親会でお話したのですが、一回解散した後に「辛いものが好き」っておっしゃってまた話しかけてくださったのが面白かったです。人生で初めて辛いものの話を人と楽しく分かり合えました。私の中でfukajunさんは登壇内容より懇親会のおしゃべりの印象が強くなってしまいました...

最後に

イベントは第1回目なのにコロナが流行っちゃって絶対運営大変だったと思うのですが、参加者としてはおかげさまで大充実の1日でした。

運営の方々、登壇者の方々、参加された皆様、関係するすべての皆様、楽しい会をありがとうございました! 道はまだまだ遠いですが、いい開発者を目指して日々を生きていこと思います。