20191115_出張！Railsウォッチ in 銀座Rails#15

2019/11/15に銀座Rails#14で発表したスライドです。
https://ginza-rails.connpass.com/event/152498/
週刊Railsウォッチ: https://techracho.bpsinc.jp/tag/%e9%80%b1%e5%88%8arails%e3%82%a6%e3%82%a9%e3%83%83%e3%83%81

Transcript

1. 出張︕Railsウォッチ in 銀座Rails#15 森 雅智 / @morimorihoge 2019/11/15 1
2. About Me • 森 雅智︓ @morimorihoge • BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤 でWeb開発を教えてたりします • Ruby/Rails歴は9年くらい。Web開発は15年くらい • 銀座Ralis #10でActiveRecordでVIEWを使おうという話をしました About BPS & TechRacho • Web受託開発や電子書籍製品開発をやっている会社です • TechRachoという自社技術Blogを運営しています ◦ 3年ほど前から平⽇毎⽇更新してます ◦ https://techracho.bpsinc.jp/ • お仕事相談、転職相談、TechRachoへのご意⾒など気軽にどうぞ ◦ https://www.bpsinc.jp/ 2
3. Railsウォッチとは︖ 技術ブログTechRachoで毎週連載しているRails / Ruby界 隈を中心とした雑多な情報を提供する技術雑談マガジン 3
4. @hachi8833（TechRacho編集部） • 八田昌三（はったしょうぞう） ◦ TechRacho記事執筆・編集・翻訳（2016.08〜） ◦ サイトメンテナンス ◦ ローカライズ業界出身 ◦ 好きなもの: 正規表現/Go/Ruby/Gobyなど多数 • やってきたこと ◦ Railsチュートリアル翻訳・翻訳ディレクション ◦ Railsガイド翻訳 ◦ Goby言語メンテナー 4 ※今日はお休み
5. これまでの出張Railsウォッチのピックアップテーマ • Rails6新機能特集 ◦ 銀座Rails#12: 複数DB対応 ◦ 銀座Rails#13: ActionText、Trix ◦ 銀座Rails#14: ActionMailbox • 大きな新機能は一通り紹介したので、今回はいくつか雑 多なテーマを取り上げます 5 ※過去のスライドはTechRachoにて公開しています。「TechRacho 銀座 Rails」あたりで検索するとヒットします
6. 11/5: Rails 6.0.1リリース • 6.0.0リリースから3ヶ月。Rails6発のマイナーアップデート ◦ 使ってる人は上げましょう • TechRachoに翻訳まとめ記事があるので、日本語で追いたい人はどうぞ ◦ https://techracho.bpsinc.jp/hachi8833/2019_11_08/82941 6
7. 11/7-8: RubyWorld Conference 2019 • 毎年島根県松江開催のBiz+Devカンファレンス ◦ 当日の#rubyworld ◦ RubyKaigiとは違い、ビジネス系の人たちも参加するのが特徴 • 毎年Rubyコミュニティに貢献した人を表彰するRuby Prizeを発表している ◦ 初日のYoutube配信︓https://www.youtube.com/watch?v=_eNObSK_Q4o ◦ 7:39:00辺りからが今年の受賞者糸柳さん（@aycabta : Rubyコミッタ & RDocの現メンテナ） の受賞スピーチ ◦ 個人的にいい話でとても刺さったのでオススメしておきます（20分くらいです） 7
8. production? development? staging? - 複数の意味があってややこしい奴ら - 8
9. 背景 9 • Rails受託開発をかれこれ8年やっていると、サーバー構成、リポジトリ管理、 deploy設計いろいろなものを⾒てきた • 中でもproduction / development / stagingという用語はプロジェクト によっては色々な意味合いを含むことがあり、混乱を招きがち • ここでは僕が経験した範囲で事例をまとめてみつつ、皆さんは同じような経 験ないですか︖的な話や良い解決策を持っている人がいたらぜひ知りたいで す
10. いろいろなXX環境 • アプリケーションの動作モードを示す ◦ RailsならRAILS_ENV • deploy先のサーバー環境を示す ◦ 本番サーバー、開発サーバーなど • Gitのブランチ・タグ名を示す ◦ developブランチなど 10
11. アプリケーションの動作モードを示す場合 • RailsにおけるRAILS_ENV • 標準ではproduction / development / test ◦ プロジェクトによっては更にstagingを増やしているケースも • 動作モードの切り替えにより以下のような振る舞いをする（一例です） ◦ productionモード ▪ 動作中にソースコードが編集されない前提が取れるため、クラスキャッシュなどをアグ レッシブに保持して効率化ができる（config.cache_classesやconfig.eager_load） ▪ 静的ファイル配信はRailsサーバーからではなくNginxなどの手前Webサーバーから配 信させる前提の設定（config.public_file_server.enabled = false） ◦ developmentモード ▪ 起動中にソースコードが編集されてもRailsサーバーの再起動不要で変更結果が反映さ れる（config.file_watcherやcache_classesの無効化など） ▪ 開発者のローカル環境ではいちいちNginxなどを⽴ち上げなくても良いように、public 以下の静的ファイルもRailsサーバーが配信する（config.public_file_server.enabled = true） ◦ testモード ▪ developmentモードに近いが、さらにCIやターミナル前提の設定などが付く （consider_all_requests_local = :stderr） 11
12. deploy先のサーバー環境を示す場合 • 端的に⾏ってしまえばcapistranoにおけるstage名 • 一般的によくある構成では production / staging / developmentくらい︖ （本当に色々なケースがある） • 本番（production）環境 ◦ サービスインしているエンドユーザーが利用する環境。git-flowならmasterブランチが対応 • 検証（staging）環境 ◦ 本番リリース前の動作検証を⾏う場所。git-flowならdevelopブランチが対応 ◦ ほとんど本番に近い環境だが、サーバースペックは落としてあったり、外部API接続がテスト 環境に繋がっていたりなどが異なる • 開発（development）環境 ◦ 開発中の機能を⾒てもらう時などに使う場所。git-flowならfeatureブランチが対応 ◦ stagingより更にカジュアルな環境で、簡単に作って潰すような使われ⽅をするためにリソー スはケチって⽴てることが多い 12 複数チームの並⾏開発が⾛ってると検証環境が複数あったり、blue-green deploymentしてるとproductionが2つあっ たりなど、ここは本当に多彩（一つの正解がない）
13. Gitのブランチ・タグ名を示す場合 • git-flowやGitHub Flowが一般的だが、プロジェクトによってはカスタマイ ズして使っていることも多々ある ◦ 特に⻑く大きく育った業務システムなんかではありがち ◦ masterやdevelopブランチをそのままdeploy時の引数として使わず、リリースタグ （release_YYYYMMDDとか）を使ってdeployするケースも • 本番ブランチ（タグ）︓ master, release/YYYYMMDD など。たまに release/productionといったタグも⾒る ◦ その時点での本番環境ソースコードと一致する • staging・リリースブランチ（タグ）︓ staging, release/YYYYMMDDなど ◦ その時点でのstaging環境ソースコードと一致する • 開発ブランチ︓feature/XXXなど ◦ PRごとに作成される機能開発ブランチ 13
14. ここまでで出てきたdouble / triple meanings • 単語だけだといろいろな意味が想像できてしまう ◦ production︓RAILS_ENV? サーバーの本番環境︖ deployするgit tag︖ ◦ staging︓RAILS_ENV? サーバーの検証環境︖ deployするgit tag︖ ◦ development︓RAILS_ENV? サーバーの開発環境︖ 14 Aさん： B君のコード、（RAILS_ENV=）production（モード）でエラーが出てるよ ー（PR レビュー中の会話） Bさん： え！本番 本番 本番 本番（サーバー）でエラーが出てる？障害やないか！やばいや んけ（あわあわ Aさん： Cさん、連携サービスのAPIキーきたからproduction（サーバー用）のconfig 設定しておいてー Cさん： ほいほい。じゃあ（RAILS_ENV=productionの） config/settings/production.ymlに置いてコミットしとくわ（大惨事
15. 自分では守っている用語ルール • RAILS_ENVを指す場合は「モード」をつける ◦ productionモード、developmentモード、など • サーバー環境を示す場合は「サーバー」を付けたり、そもそも別の単語を使 う ◦ prodサーバー、stgサーバー、など • Gitのブランチ・タグを示す場合はブランチ、タグであることを明示する ◦ stagingブランチ、productionタグなど 15 自分では守ってるけど人によっては通じない人もいるし、そもそも途中参加のプ ロジェクトの場合は命名変更する権限がないことも多い（つらい production / prodとあえて書き分けしてるのに、producitonの意味でprodを使 う人なんかも出てきたりして割とカオス（なおつらい
16. おまけ︓stagingの概念が人によって違いすぎる問題 皆さんのプロジェクトの「staging（検証）環境」、どんな使われ⽅してます か︖ • ほぼ本番と同じ環境 ◦ サーバー台数・スペックも同じかほぼ近い（複数台アプリサーバーなども） ◦ DBも本番から個人情報maskした程度で件数も同等 ◦ バッチ系や外部API連携も適切に動いている • アプリケーションレベルでは本番と同じ環境 ◦ Appサーバー台数は1台で、本番とは異なる ◦ DBは本番データではなく検証・テスト用データが入っている。データ件数は少なめ • 開発環境と検証環境は分かれていないが、便宜上stagingと呼んでいる ◦ 各エンジニアが割とカジュアルにdeployして使って検証に使っている ◦ 検証環境と開発環境は共有していて、カジュアルにリリースしている 16 銀座Railsに参加しているみなさんはいかがでしょうか︖ ※プロジェクトの規模や⽅針、リソースにもよるので、良い悪いの話ではないです
17. 宣伝︓週刊Railsウォッチ 公開つっつき会 • 毎月第一木曜⽇、社外の⽅も参加できる公開つっつき会 を開催してます ◦ 次回は2019/12/5（木）19:30〜＠⻄新宿 BPS会議 スペースにて（予定） • TechRachoの週刊Railsウォッチの最新記事、または「週 刊Railsウォッチ公開つっつき会」でぐぐってご参加下さ い︕ 17
18. 次回以降もブラッシュアップしていきます 感想・リクエストなどあればTwitter #ginzarails @morimorihoge @hachi8833 までお声かけください 18