デプロイ完全自動化から1年で起きたこと /ikyu-deploy

D7cdf68e7d8699d99ff2e752458e71fb?s=47 minato128
February 09, 2017

デプロイ完全自動化から1年で起きたこと /ikyu-deploy

D7cdf68e7d8699d99ff2e752458e71fb?s=128

minato128

February 09, 2017
Tweet

Transcript

  1. デプロイ完全自動化から1年 で起きたこと 株式会社一休 株式会社一休 宿泊事業本部システム開発部 飯迫 正貴 2017/02/09 CI/CD NIGHT

    LT
  2. 背景 背景

  3. 背景 • 2015/10 デプロイ完全自動化 – master branch merge • =>

    Staging deploy – release branch merge – release branch merge • => Production deploy – 本番デプロイは週2回から4回に(当番制) • 2016/0x~ クラウド移行に向けて取組み を開始
  4. 詳しくはこちらで https://speakerdeck.com/kensuketanaka/ikyu-deploy-flow

  5. 前提 • スコープは宿泊システム • GHE => Jenkins => Data Center

    • Git リポジトリは n GB – 軽量化の取組み中 – https://speakerdeck.com/kensuketanaka/ikyu- storage-improvement storage-improvement • 同じリポジトリでデザインデプロイも行っている • デザインデプロイとは? – デザイナーが使うデプロイフロー – 差分でリアルタイムデプロイ – d/xxxx branch を対象として Jenkins 側で処理させてい る • システムは f/xxxx branch
  6. デプロイ完全自動化から 1年で起きたこと デプロイ完全自動化から 1年で起きたこと

  7. 序章 • 2016/04 – @kentana20 人事異動 – CI/CDまわりのメンテが引き継がれる – CI/CDまわりのメンテが引き継がれる

    • かなり属人化していた • 2016/06 – 宿泊のエンジニアが急に増える
  8. 人が増えると • コミット/マージ数も増える • Staging 環境が常時デプロイ状態になる – Staging環境で動作確認ができない – システムデプロイ中はデザインデプロイがで

    – システムデプロイ中はデザインデプロイがで きないので、デザイナーも困る – 鳴り止まないE2Eエラー
  9. 人が増えると • 本番デプロイ切り戻しも増える • WEBサーバーを前半後半に分けてデプロ イしていて自動化されているが、切り戻 しは手動で行っていた しは手動で行っていた – 当番制ではあるが、自動化された部分以外は

    メンテナに頼りがち – 酷いときは週の半分くらいデプロイトラブル 対応 • つらい • 自分の仕事ができない
  10. ひとりじゃ抱えきれない ひとりじゃ抱えきれない

  11. そこで そこで

  12. #deploy-working-group 結成 • 2016/09 – 各チームからひとり選出 – CI / CD

    まわりの属人化を防ぐ – タスク分散 – タスク分散 – レビュー
  13. デプロイワーキンググループ

  14. デプロイワーキンググループ

  15. やったこと やったこと

  16. Staging デプロイ高速化 • そもそも遅すぎた – 30分以上かかっていた • リソース配置がSYNCサーバー頼み • Production

    より簡素な仕組み • リファクタリング – Jenkins Job – Script (JS/Ruby) – Script (JS/Ruby) – symlink の活用 – ついでに Production も高速化 • SYNCサーバーからの脱却 • @midnight git gc • 最終的に15分で終わるように • 高速化ではないが、デプロイトリガーも見直し – master branch merge ではなく、数時間ごとの定期実行に変更 – こっちのほうが Staging 環境が安定する
  17. 失敗に強くする • デプロイ切り戻しの自動化 – ロールバック Job を作成 • リトライできるように –

    Jenkins Job チェーンがリトライでリカバリーで きなかった きなかった • GitHub payload を同じファイルに常に上書きして後 続処理でも参照していた • ファイル名にビルド番号を付与して後続に渡すように 変更 – design_payload.[ビルド番号].json • 資料整備・共有 – 口頭での周知も
  18. 資料整備・共有

  19. その他 • Selenium E2E • ユニットテスト • ブランチデプロイ環境 • GHEアップデートによる

    payload 内容変更 • COM問題 GHEアップデートによる payload 内容変更 • COM問題 など デプロイだけでなく CI/CD まわりの大小さま ざまな問題に対応
  20. 一方、他のアプリは 一方、他のアプリは

  21. 順調にクラウドへ • 新しく作っているサービス – .NET Core – GitHub => Circle

    CI => AWS – リリース済み • 既存の Classic ASP • 既存の Classic ASP – GitHub => AppVeyor => AWS – 検証終了 – リリース直前 • 既存の ASP.NET MVC / Web API – GitHub => AppVeyor => AWS – 検証終了 – リリース直前
  22. まとめ まとめ

  23. まとめ(と得た教訓) • 継続的改善 – 改善スコープの見極め大事 • (クラウド化などで)解決する見込みがある領域に安易に踏み 込まない – コスパを考える

    • CI / CD は目的ではない グループで取り組む CI / CD は目的ではない • グループで取り組む – ひとりだとつらすぎる – 属人化も防ぎたい • CI / CD はできるだけシンプルな構成に保つ • 複雑化するとメンテも大変 • アプリケーションもできるだけシンプルな構成に保つ • aka デフォルト厨 / サンプルアプリケーションのような構成 • PaaS に載せられる状態がよい