$30 off During Our Annual Pro Sale. View Details »

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

minato128
February 09, 2017

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

minato128

February 09, 2017
Tweet

More Decks by minato128

Other Decks in Programming

Transcript

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

    View Slide

  2. 背景
    背景

    View Slide

  3. 背景
    • 2015/10 デプロイ完全自動化
    – master branch merge
    • => Staging deploy
    – release branch merge
    – release branch merge
    • => Production deploy
    – 本番デプロイは週2回から4回に(当番制)
    • 2016/0x~ クラウド移行に向けて取組み
    を開始

    View Slide

  4. 詳しくはこちらで
    https://speakerdeck.com/kensuketanaka/ikyu-deploy-flow

    View Slide

  5. 前提
    • スコープは宿泊システム
    • GHE => Jenkins => Data Center
    • Git リポジトリは n GB
    – 軽量化の取組み中
    – https://speakerdeck.com/kensuketanaka/ikyu-
    storage-improvement
    storage-improvement
    • 同じリポジトリでデザインデプロイも行っている
    • デザインデプロイとは?
    – デザイナーが使うデプロイフロー
    – 差分でリアルタイムデプロイ
    – d/xxxx branch を対象として Jenkins 側で処理させてい

    • システムは f/xxxx branch

    View Slide

  6. デプロイ完全自動化から
    1年で起きたこと
    デプロイ完全自動化から
    1年で起きたこと

    View Slide

  7. 序章
    • 2016/04
    – @kentana20 人事異動
    – CI/CDまわりのメンテが引き継がれる
    – CI/CDまわりのメンテが引き継がれる
    • かなり属人化していた
    • 2016/06
    – 宿泊のエンジニアが急に増える

    View Slide

  8. 人が増えると
    • コミット/マージ数も増える
    • Staging 環境が常時デプロイ状態になる
    – Staging環境で動作確認ができない
    – システムデプロイ中はデザインデプロイがで
    – システムデプロイ中はデザインデプロイがで
    きないので、デザイナーも困る
    – 鳴り止まないE2Eエラー

    View Slide

  9. 人が増えると
    • 本番デプロイ切り戻しも増える
    • WEBサーバーを前半後半に分けてデプロ
    イしていて自動化されているが、切り戻
    しは手動で行っていた
    しは手動で行っていた
    – 当番制ではあるが、自動化された部分以外は
    メンテナに頼りがち
    – 酷いときは週の半分くらいデプロイトラブル
    対応
    • つらい
    • 自分の仕事ができない

    View Slide

  10. ひとりじゃ抱えきれない
    ひとりじゃ抱えきれない

    View Slide

  11. そこで
    そこで

    View Slide

  12. #deploy-working-group 結成
    • 2016/09
    – 各チームからひとり選出
    – CI / CD まわりの属人化を防ぐ
    – タスク分散
    – タスク分散
    – レビュー

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. Staging デプロイ高速化
    • そもそも遅すぎた
    – 30分以上かかっていた
    • リソース配置がSYNCサーバー頼み
    • Production より簡素な仕組み
    • リファクタリング
    – Jenkins Job
    – Script (JS/Ruby)
    – Script (JS/Ruby)
    – symlink の活用
    – ついでに Production も高速化
    • SYNCサーバーからの脱却
    • @midnight git gc
    • 最終的に15分で終わるように
    • 高速化ではないが、デプロイトリガーも見直し
    – master branch merge ではなく、数時間ごとの定期実行に変更
    – こっちのほうが Staging 環境が安定する

    View Slide

  17. 失敗に強くする
    • デプロイ切り戻しの自動化
    – ロールバック Job を作成
    • リトライできるように
    – Jenkins Job チェーンがリトライでリカバリーで
    きなかった
    きなかった
    • GitHub payload を同じファイルに常に上書きして後
    続処理でも参照していた
    • ファイル名にビルド番号を付与して後続に渡すように
    変更
    – design_payload.[ビルド番号].json
    • 資料整備・共有
    – 口頭での周知も

    View Slide

  18. 資料整備・共有

    View Slide

  19. その他
    • Selenium E2E
    • ユニットテスト
    • ブランチデプロイ環境
    • GHEアップデートによる payload 内容変更
    • COM問題
    GHEアップデートによる payload 内容変更
    • COM問題
    など
    デプロイだけでなく CI/CD まわりの大小さま
    ざまな問題に対応

    View Slide

  20. 一方、他のアプリは
    一方、他のアプリは

    View Slide

  21. 順調にクラウドへ
    • 新しく作っているサービス
    – .NET Core
    – GitHub => Circle CI => AWS
    – リリース済み
    • 既存の Classic ASP
    • 既存の Classic ASP
    – GitHub => AppVeyor => AWS
    – 検証終了
    – リリース直前
    • 既存の ASP.NET MVC / Web API
    – GitHub => AppVeyor => AWS
    – 検証終了
    – リリース直前

    View Slide

  22. まとめ
    まとめ

    View Slide

  23. まとめ(と得た教訓)
    • 継続的改善
    – 改善スコープの見極め大事
    • (クラウド化などで)解決する見込みがある領域に安易に踏み
    込まない
    – コスパを考える
    • CI / CD は目的ではない
    グループで取り組む
    CI / CD は目的ではない
    • グループで取り組む
    – ひとりだとつらすぎる
    – 属人化も防ぎたい
    • CI / CD はできるだけシンプルな構成に保つ
    • 複雑化するとメンテも大変
    • アプリケーションもできるだけシンプルな構成に保つ
    • aka デフォルト厨 / サンプルアプリケーションのような構成
    • PaaS に載せられる状態がよい

    View Slide