Development and Deployment at PLAID

Transcript

1. PLAIDにおけるCI/CD環境 PLAID, Inc. Yoshiyuki Komazaki

2. Yoshiyuki Komazaki Tech Lead @ PLAID, Inc.

3. 今日話すこと PLAIDでの開発からリリースまでの全体像 特別なことをやっているわけではないが、何かしらの参考になれば。 意外と他の開発事情って知らない？ フローとか使用しているツールとか。

4. 目次 1. 何を開発しているか 2. 開発フロー 3. リリースフロー 4. 今後の課題

5. 目次 1. 何を開発しているか 2. 開発フロー 3. リリースフロー 4. 今後の課題

6. Customer Experience Platform ユーザーを理解する アクションする サイトに訪れたユーザーの体験を向上させるためのプラットフォーム

7. Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute

   Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery Stride Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Tracker.js Cloud CDN Realtime Layer or Cloud Front AWS JS/ SDK/ API Redislabs ... Stackdriver Stride 全体構成

8. Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute

   Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery Stride Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Tracker.js Cloud CDN Realtime Layer or Cloud Front AWS JS/ SDK/ API Redislabs ... Stackdriver Stride 開発体制 リリース頻度 ※今回の話に関わる範囲 + Ops用リポジトリ + ライブラリ等 ： 1 ： 約 30名 ： 1回以上 / 日 リポジトリ数 開発者数

9. 目次 1. 何を開発しているか 2. 開発フロー 3. リリースフロー 4. 今後の課題

10. Git Flow A successful Git branching model https://nvie.com/posts/a-successful-git-branching-model/

11. BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4. “shipit”のラベル 5.

    developブランチに自動マージ 開発フロー Reviewer Developer

12. BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4. “shipit”のラベル 5.

    developブランチに自動マージ 開発フロー Reviewer Developer

13. BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4. “shipit”のラベル 5.

    developブランチに自動マージ 開発フロー Reviewer Developer

14. BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4. “shipit”のラベル 5.

    developブランチに自動マージ 開発フロー Reviewer Developer

15. Reviewer Developer BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4.

    “shipit”のラベル 5. developブランチに自動マージ shipit 開発フロー

16. BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4. “shipit”のラベル 5.

    developブランチに自動マージ 開発フロー shipit Reviewer Developer

17. Reviewer Developer BOT 1. featureブランチで開発してPR 2. 自動Test 3. Review 4.

    “shipit”のラベル 5. developブランチに自動マージ 開発フロー shipit shipit && テストが通っている && リリース中ではない時

18. 目次 1. 何を開発しているか 2. 開発フロー 3. リリースフロー 4. 課題と今後

19. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

20. Spinnaker is an open source, multi-cloud continuous delivery platform for

    releasing software changes with high velocity and confidence. Spinnaker https://www.spinnaker.io

21. 弊社SREチームの@ikemonnが builderscon tokyo 2018で発表してきました！詳しくはブログで！ Netflix発のOSS"Spinnaker"でマルチクラウドにデプロイしている話 Spinnaker https://tech.plaid.co.jp/builderscon-2018/

22. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

23. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

24. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境でE2E Test 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ 平日毎朝8:00頃に自動で作成 リリースフロー

25. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

26. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

27. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

28. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー 自動テスト + 手動テスト テスト化ができていないものは一部手動...

29. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

30. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー Botが実行するコマンドは 基本的にSlackからでも手動実行可能。 （Fabricで定義されている）

31. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

32. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー 基本的な機能が動くか バグが出ていないか メトリクスを見て異常がないか

33. 1. Releaseブランチ作成 2. Test & Build待ち 3. 検証環境にリリース 4. 検証環境で動作確認

    5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ BOT 検証環境 本番環境 リリースフロー 基本的な機能が動くか バグが出ていないか メトリクスを見て異常がないか 問題あればロールバック

34. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分だけ手動確認 7. master/developにマージ リリースフロー

35. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境でE2E Test 5. Slack経由で本番環境にリリース 6. クリティカルな部分だけ手動確認 7. master/developにマージ リリースフロー ここの自動マージが落ちると面倒なので リリース中はdevelopへのマージを止めている

36. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境でE2E Test 5. Slack経由で本番環境にリリース 6. クリティカルな部分だけ手動確認 7. master/developにマージ リリースフロー

37. リリース完了 リリース完了時に関連issue一覧をSlackに通知。 その日リリースされたものはここで大体把握。

38. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー

39. BOT 検証環境 本番環境 1. Releaseブランチ作成 2. Test & Build待ち 3.

    検証環境にリリース 4. 検証環境で動作確認 5. Slack経由で本番環境にリリース 6. クリティカルな部分の動作確認 7. master/developにマージ リリースフロー 4 ~ 6以外は自動 （5.はSlackで打つだけ）

40. リリースは１日１回だけ？ 日々のリリース終了後も、その日に入れた方が良い、または別でリリースした方がよい と判断したものはhotfixとして入ります。 関連するサーバグループ毎にリリースすることもできるようになっています。

41. 目次 1. 何を開発しているか 2. 開発フロー 3. リリースフロー 4. 今後の課題

42. 今後の課題 • 手動確認を減らす • レビューの時間を短縮 • テストの時間を短縮 • リリースサイクルを速める

43. 手動確認を減らす テストしづらい部分が残っている。ServiceWorkerのテストなどなど。 今後の課題

44. レビューの時間短縮 PRのレビュー時、ブランチ切り替えてローカル動作確認するというのは手間。 PRを作った時点でその環境を一時的に作って動作確認できる状態だと最高。 • CircleCIの環境をそのまま？ • Kubernetesでnamespaceをわけて..？ 今後の課題

45. テスト時間短縮 現状は全テストを全PRで実行している。E2Eテストも増えてきた。 • Googleのいうテストレベル（S, M, L）のような概念でわけて必要なものを必要なタ イミングで実行？ • 外部との通信が必要ないものはエミュレータ/stubを使用 今後の課題

46. リリースサイクルを速める 現状は基本的にはある時点のものをまるっとテストしリリースしている。 • 各コンポーネントの責任範囲、ファイルの影響範囲を明確化？ • いわゆるMicroService？ • とはいえ細かくしすぎたくはない • リポジトリが増えるのも大変なのでそれは避けたい

    今後の課題

47. まとめ 今日話したこと 1. 何を開発しているか 2. 開発フロー 3. リリースフロー 4. 今後の課題

    PLAIDでの開発からリリースまでの全体像

48. We are hiring! Blog紹介とか宣伝。いい写真 Thank you. PLAID Engineer Blog：https://tech.plaid.co.jp