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

CI/CD NIGHT LT
https://teamspirit.connpass.com/event/49323/

Transcript

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
   – 本番デプロイは週２回から４回に（当番制）
   • 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. デプロイ完全自動化から
   １年で起きたこと
   デプロイ完全自動化から
   １年で起きたこと
   

   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