heyにおけるCI/CDの現状と課題

Slide 1

Slide 1 text

　　 ©hey, Inc heyにおけるCI/CDの現状と課題プロダクト基盤本部 SRE 藤原涼馬

Slide 2

Slide 2 text

自己紹介藤原涼馬ヘイ株式会社プロダクト基盤本部 SRE (他にもいろいろ) 経歴　SIer R&D →　　　　　　→ 趣味　自動車の運転　模型製作　各種寄稿・登壇好きなAWSサービス　ECS Fargate / AWS SSO + 他いろいろ今ここ

Slide 3

Slide 3 text

目次 ● そもそもCI/CDの目的ってなんだっけ? ● heyにおけるCI/CDの現状 ● 今後どうしたい?という話

Slide 4

Slide 4 text

CI/CDの目的ってそもそも何？ ● CIもCDも基本的には、 ”誰でも、いつでも同じ品質でタスクを実行する”ことを目的としています ● CI(Continuous Integration; 継続的インテグレーション) ○ リポジトリに格納されているコードを自動的にビルド・テストする手法 ref) https://aws.amazon.com/jp/devops/continuous-integration/ ● CD(Continuous Deploy/Delivery; 継続的デプロイ/デリバリー) ○ リポジトリに格納されているコードを自動的に本番環境に配置、配布する手法 ○ デプロイ...トリガーまで自動化 ○ デリバリー... トリガーは手動

Slide 5

Slide 5 text

CIを導入することで得られるもの ● 個々人のローカル環境に依存しない形でテストが実行できる ● コードに沿って機械がテストを実行するので、何回でも確実に同じ手順で実行される(手順を読み間違えて作業するといったことが起きづらい) ● コードに沿ってアプリケーションをビルドするので、誰が実行しても成功 or 失敗が明確

Slide 6

Slide 6 text

CI/CDを導入することで得られるもの ● 個々人のローカル環境に依存しない形でテスト・ビルド・デプロイが実行できる ● コードにそって機械がテストを実行するので、誰が実行しても確実に同じ手順で実行される ● コードにそって機械がアプリケーションをビルドするので、誰が実行しても成功 or 失敗が明確 ● コードにそって機械がアプリケーションをデプロイするので、誰が実行しても成功 or 失敗が明確属人性の削減と高いテスト・デプロイ頻度が得られる

Slide 7

Slide 7 text

CI: 高頻度で自動テストを実施することの重要性不具合の修正にかかるコストを最小化する不具合が混入してから長時間経ってから対応するよりも対応コストは低くなる https://speakerdeck.com/fufuhu/devopsdao-ru-zhi-nan-2020nian-du-ban?slide=164より

Slide 8

Slide 8 text

CD: デプロイ頻度の重要性エンジニアリング観点とビジネス観点に分けて解説

Slide 9

Slide 9 text

CD: エンジニアリング観点でのでデプロイ頻度の重要性高頻度でデプロイすることによる差分の極小化とそれに伴うMTTRの縮小低頻度デプロイ時間変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更デプロイデプロイ不具合発生高頻度デプロイ時間変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更変更デプロイデプロイ不具合発生デプロイデプロイデプロイ過去の変更に伴うものが爆発したのでなければこの部分の変更が原因の可能性が高い

Slide 10

Slide 10 text

Slide 11

Slide 11 text

CD: ビジネス観点でのデプロイ頻度の重要性機能が早くリリースされるほど利用者への提供価値の総和は大きくなる低頻度デプロイ高頻度デプロイ時間提供価値時間提供価値機能1 機能1 機能2 機能3 機能4 機能5 差分機能2 機能3 機能4 機能5 差分リリースせずに寝かせている期間リリースせずに寝かせている期間デプロイデプロイデプロイデプロイデプロイデプロイデプロイデプロイ

Slide 12

Slide 12 text

Slide 13

Slide 13 text

ここまでのまとめ高い頻度でCIを回すし、CDも回した方がお得ですよ

Slide 14

Slide 14 text

heyにおけるCI/CDの現状

Slide 15

Slide 15 text

現状の概要 ● 現時点で全社的なルールが明確にあるわけではない ● ある程度仕組みや方法論を揃えていきたいといった雰囲気は感じる ○ 標準化とは行かなくても他プロダクトの良いところを取り込んだり、すでに直面した課題は回避したいと思っている ○ e.g. CI上のテストで積極的にモックを使うのか使わないのか？など ● いわゆるCIやCDの品質とか成熟度といった部分はプロダクトによって異なる ● なんとなく課題感はある

Slide 16

Slide 16 text

個別プロダクトの状況 CIは全てのプロダクトに存在しています。実施している内容や深さはプロダクトによって異なります。プロダクト1 プロダクト2 プロダクト3 プロダクト4 プロダクト5 CI ・Circle CI ・PR単位でlintとテスト CD ・Circle CI ・mainブランチプッシュでリリース CI ・CircleCI(テスト) ・GitHub Actions 　(コンテナイメージビルド) CD ・Rundeck CI ・CircleCI -> GitHubActions ・lint, テスト(rspec, jest), E2E(mabl) CD ・GitHub Actions(chat ops with slack) 　ECS… ecspresso + CodeDeploy 　EC2… capistrano CI ・GitHub Actions ・テスト, Codacy(静的解析) CD ・GitHub Actions 　ECS … CodeDeploy 　EB … Swap URL CI ・GitHub Actions (C)D ・ローカルからの独自スクリプト

Slide 17

Slide 17 text

全体的な傾向 ● CI基盤としてはCircleCI、GitHub Actions(+ 一部で追加のSaaSを利用) ● CDについては多少幅が出てきます ○ CircleCI, GitHub Actions, Rundeck, (+ 独自スクリプト) ○ コンピューティング基盤は徐々にECSに寄せていこうとしています

Slide 18

Slide 18 text

(プロダクトによっては)やってること ● トランクベース開発 ● E2Eテスト ○ mablを活用した STORES 予約のE2Eテスト戦略 - hey Product Blog ● フィーチャートグルの導入 ● CIパフォーマンスの測定

Slide 19

Slide 19 text

現状の課題(とやりたいこと) ● プロダクトによってはデプロイに要する時間が長く、頻度を上げるための改善をしたい ● デプロイ容易性などを上げる目的でECS移行を進めているプロダクトがある ● 特定プロダクトの良い取り組みを他にも広めたい ○ CIのモニタリング/E2Eテスト/フィーチャートグル ● CI/CDにおける機密情報管理、セキュリティレベルの底上げ (現時点では具体的に問題が生じているわけではないが) ○ AWSへのアクセスはOIDCベースに移行したい(GitHub ActionsでAWSのアクセスキーを管理したくない)

Slide 20

Slide 20 text

Slide 21

Slide 21 text

まとめ ● 前段セッションでもあった通り、SLO/SLI策定や測定するための仕組み作りは重要です ● それ以上にそもそも高いSLIを実現するにはインフラとアプリケーションそのものが重要です。CIの整備を通じてテストを高頻度で実行し、アプリケーションコードの特性を可視化して改善をすすめられるようにしておきましょう。 ● また、アプリケーションが無事にデプロイ出来なければSLOもSLIもありません。ダウンタイムのより少ないデプロイ手法、より確実なデプロイ手法の実現のためにCDを磨き込んでいきましょう。 ● heyのプロダクトでもCI/CDについては状況はまちまちな状態です。取り組みたい事はCI/CDに限らずたくさんあります。CI/CDが何を果たしているのかを理解した上で適切な優先順位付けをしてより良くしていくための取り組みを進めたいと考えています。

Slide 22

Slide 22 text

ご清聴ありがとうございました