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