Middlemanを使用した静的サイトの運用事例
•
1 gefällt mir•886 views
Tokyo Middleman Meetup #3 で発表した内容 導入の経緯と実際のアーキテクチャ、運用の流れをかるーくご紹介
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Middlemanを使用した静的サイトの運用事例
Ähnlich wie Middlemanを使用した静的サイトの運用事例 (20)
Middlemanを使用した静的サイトの運用事例
- 1. Middlemanを使用した 静的サイトの運用事例 2017-05-19 (Fri.) Tokyo Middleman Meetup #3 ぷぽ / @pupupopo88 ＼のケース／
- 2. エンジニア BtoBtoC向けサービス開発運用保守 総務 採用・研修・庶務・広報 2012年 2016年 2013年 2014年 2015年 2017年 ＼自己紹介／ エンジニア BtoC向けサービス開発運用保守 はじめて外部の”勉強会”に参加 ※ Tokyo Middleman Meetup #1 !!
- 3. エンジニア BtoBtoC向けサービス開発運用保守 2012 2016年 2013 2014 2015年 2017年 ＼この辺の話／ エンジニア BtoC向けサービス開発運用保守 はじめて外部の”勉強会”に参加 ※ Tokyo Middleman Meetup #1 !! 総務 採用・研修・庶務・広報
- 6. Background
- 8. ❖ 元のサイトは外注 ❖ サイトは総務が管理（管理できるとは言っていない） ❖ サーバなどインフラ周りは別途情シス部門が管理 ❖ ビジネス部門にデザイン業務をおこなうチームが新設 ❖ 元エンジニア（私だ）が人事異動で総務へ 当時 (2014/07) の状況 外注してたけれどイケてないし IT企業なんだから内製できないの？
- 9. ❖ 開発メイン担当、全員がRuby経験者だった ❖ 元エンジニア and 新人研修でRuby触ってる ❖ 勉強会やらでMiddlemanの存在は知っていた ❖ やっぱり冗長なこと、面倒なことはやりたくなかった ❖ 毎ページにヘッダとフッタを記述するとか ❖ 生のCSSを書くとか ❖ 早くつくりたかった ❖ 緊急時など、最悪静的ファイルをいじって更新してもらえる なぜMiddlemanだったのか
- 10. Architecture
- 12. Maintenance
- 13. ❖ 開発環境ある人、メンテできる人だけで完結 ❖ ローカル環境でビルド ❖ AWSのマネジメントコンソールから手動でアップロード ❖ Stagingに上げたので確認してくださいとプルリク ❖ OKもらう（マージボタンを押してもらうことは可能） ❖ Productionにマネジメントコンソールから… ❖ Shellやバッチも作ったけれどそれも環境が… はじめは
- 14. ❖ 私が再びの異動 ❖ そのまま仕事もっていくのなんてゴメンだ！ ❖ しかし、不毛な教育もしたくない（それも手間） ラクにするためだったのに無理に・不用意に学習させるのも ❖ 自動化の機運高まる！ ❖ あまり手間をかけず ❖ 最低限の学習コストで ❖ ある程度のことができるように その後
- 16. Staging
- 17. $ git push origin modify/recruit_pages
- 18. $ git push origin modify/recruit_pages Post
- 19. $ git push origin modify/recruit_pages
- 20. $ git push origin modify/recruit_pages Deploy staging_root/modify/recruit_pages staging
- 21. $ git push origin modify/recruit_pages Post staging_root/modify/recruit_pages staging
- 22. Production
- 25. New tag v20170519 delete : staging_root/modify/recruit_pages deploy : staging_root staging
- 26. New tag v20170519 delete : staging_root/modify/recruit_pages deploy : staging_root staging production Deploy
- 27. New tag v20170519 delete : staging_root/modify/recruit_pages deploy : staging_root staging production Deploy Clear cache
- 28. New tag v20170519 Post delete : staging_root/modify/recruit_pages deploy : staging_root staging production Deploy Clear cache
- 29. ❖ ローカルで確認しなくていい（開発環境なくてもOK） ❖ stagingで複数バージョンの確認ができる ❖ / はproduction環境と同じ、あとはブランチ名で ※そしてmasterにマージされているものは自動で消える ❖ 複数の変更をまとめてリリースできる ❖ 安心・安全・ラクチン ❖ タグ付けだけならGitHub上で簡単にできる ❖ うっかり間違えてもタグ付けで前のバージョンに戻せる この構成のメリット
- 30. Demo
- 31. Good Point
- 32. ❖ 簡単に部分テンプレート作れるところとか ❖ 修正し忘れとかが減る（と思う） ❖ ちょっとした条件で出し分けしたりだとか ❖ JSONデータを持っといてeach回すだとか ❖ とりあえずSass最高 ❖ いろんなサービスと連携することによって更にラクに！ やっぱりラク
- 33. Problem
- 34. ❖ どんどんレガシー化する ❖ Middlemanもまだv3、実はRubyも2.1.2、やばい ❖ メインで使っている人たちがエンジニアではない ❖ やろうと思えばできる人もいるけれどやっぱり後回し ❖ 社内にはできる人も沢山いるけれど もちろん自分が持っているプロダクトが最優先 ❖ 一番面倒なのは、バージョンを上げたことで メイン利用者の開発環境に問題が起きること メンテ人員がいないとつらい
- 35. ❖ 特にまったくの非エンジニア ❖ 環境づくりのサポートも手間（特にWindowsとかヤダ） ❖ 環境のサポートとお膳立てができれば、 ちょっとした変更なんかはできると思う ❖ Gitを使う（連携させる）ならなおさら ❖ Gitの有用性を実感してもらいにくいので、 覚えようというモチベに繋がりにくい ❖ Fix typo で Git 使ってもらうってのも…（でもGUIなら） ❖ ただしGitHubでのプルリク確認&コメント、 マージボタンをクリックするだけなら全然できる ラクになるまでのコストが高い
- 36. Middlemanは最高！
- 37. ただし ご利用は計画的に
- 39. ❖ エンジニア職 ❖ 駅すぱあとをベースとするC向けサービスの開発・運用・保守 ❖ Ruby（Rails 4.2以上）メイン ❖ RubyやJSなどフロント側が好き・強みがある方 インフラ周り（特にAWS）が好き・強みがある方 ❖ マーケティング職 ❖ 駅すぱあとをベースとするサービスの マーケティング/販売促進活動の企画、広告営業活動 ❖ 企業サイトも触ってますが、 GitとかRubyとかできなくても大丈夫です笑 一緒にはたらく人募集中！