Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Development and Deployment at PLAID

656add9eb99a19889a99592ec588aa50?s=47 Yoshiyuki Komazaki
September 13, 2018
Technology
1
300

Development and Deployment at PLAID

656add9eb99a19889a99592ec588aa50?s=128

Yoshiyuki Komazaki

September 13, 2018
Tweet

More Decks by Yoshiyuki Komazaki

See All by Yoshiyuki Komazaki
656add9eb99a19889a99592ec588aa50?s=48 komukomo
1
740
656add9eb99a19889a99592ec588aa50?s=48 komukomo
2
440

Other Decks in Technology

See All in Technology
Fb025419ed38f98df595eb2eafc859f4?s=48 ihcomega56
1
350
3115a782126be714b5f94d24073c957d?s=48 oracle4engineer
1
430
F4d37a67ce86b2f962c79d73a9127d3c?s=48 fortkle
0
430
23f4d5d797a91b6d17d627b90b5a42d9?s=48 kentaro
2
210
53850955f15249a1a9dc49df6113e400?s=48 line_developers
PRO
1
320
61e7dc2e84a1a1c4ac1a8e2c552fee07?s=48 tutsunom
1
140
A64ac825509279a770c13c6fc517f11a?s=48 kawaguti
0
110
73dfdf58c8072916f1b4c62c93279fd7?s=48 yuzoiwasaki
0
160
2c4ef0f20c4f05ca30e6c9917f0c17b6?s=48 okuken
0
310
Fb89953d3a1b1fcb862a186585c37c25?s=48 fabiangosebrink
0
210
73560128b23de542e47a318145bc781a?s=48 kawanamiyuu
4
690
C65a5dd24a6781ffc618377347a0c48a?s=48 asahi_k2
0
690

Featured

See All Featured
C0390e8b11079f8761c0cd3274ed61cb?s=48 productmarketing
6
760
39488f9d172ab92fd352f2cd7b73258d?s=48 mza
80
4.2k
8ec1383b240b5ba15ffb9743fceb3c0e?s=48 philnash
10
650
Ded01cdab114abe4ec13511e4c25b9bb?s=48 andyhume
64
3.8k
3d6ace9554821d552146413bcdf874f6?s=48 trishagee
24
3k
E43f8dfd01057f8304f5f8fb9a294d7d?s=48 jeffersonlam
330
15k
A16eb159db895e3b01d3dc95767ad595?s=48 jonyablonski
20
1.3k
B6a8f005f39d23ffc930508ac9da68b9?s=48 vanstee
117
4.9k
F57e2136eb9895eb95ff5dc8a1c02677?s=48 zakiwarfel
88
3.4k
5b9fe87ec1faa67a4599782930f45ec9?s=48 sstephenson
146
12k
B3d6434763caa0ef5dc4b792662c49f7?s=48 smashingmag
232
18k
462dad0dd24c568a32dcdb0ae895ae1b?s=48 rasmusluckow
318
18k

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