Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

37b01da9150c1e789f35771b06d36890?s=47 Masato Mori
November 15, 2019

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

37b01da9150c1e789f35771b06d36890?s=128

Masato Mori

November 15, 2019
Tweet

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