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

背景 背景

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

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

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

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

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

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

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

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

そこで そこで

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

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

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

やったこと やったこと

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

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

資料整備・共有

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

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

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

まとめ まとめ

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