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

Development and Deployment at PLAID

Yoshiyuki Komazaki
September 13, 2018
Technology
1
480

Development and Deployment at PLAID

Yoshiyuki Komazaki

September 13, 2018
Tweet

More Decks by Yoshiyuki Komazaki

See All by Yoshiyuki Komazaki
GKE Security and Services
komukomo
1
1.2k
Migrating to Microservices
komukomo
2
610

Other Decks in Technology

See All in Technology
レガシーになりゆく システムとの向き合い方 / 20221005_inoue
rakus_dev
0
110
大学で情報工学を専攻しつつ、その道を一度外れてまた情報工学の分野に戻ってきた男が語る「データを用いた仕事の面白さ」
sagara
0
100
Using Change Data Capture for Stack Modernization
kamorisan
0
1.7k
カラーミーショップの改善におけるSRE活動について
homirun
0
270
週刊タイピングは役に立たない
chizuchizu
0
120
Protect your backends with Firebase App Check
firebasethailand
0
330
リリースした製品のユーザー問い合わせ対応負荷を減らす施策例
bitkey
PRO
0
150
開発支援のための組織体制 〜ゆめみの情報共有と成長環境〜 / abceed Tech Night yumemi
usamik26
0
250
JaSST Review 22 Introduction / JaSST Review'22 内容紹介
nihonbuson
0
170
layerx-bakuraku-how-to-achieve-agility-and-security
shnjtk
1
170
How to build a minimum lovable product
andreasaez
1
120
Symfony Serializer Deep Dive
suzuki
0
240

Featured

See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
182
15k
Clear Off the Table
cherdarchuk
79
290k
Fantastic passwords and where to find them - at NoRuKo
philnash
29
1.7k
The Mythical Team-Month
searls
210
40k
Learning to Love Humans: Emotional Interface Design
aarron
261
37k
Automating Front-end Workflow
addyosmani
1351
200k
4 Signs Your Business is Dying
shpigford
169
20k
Designing on Purpose - Digital PM Summit 2013
jponch
107
5.7k
Facilitating Awesome Meetings
lara
31
4.2k
Keith and Marios Guide to Fast Websites
keithpitt
405
21k
Support Driven Design
roundedbygravity
87
8.7k
Robots, Beer and Maslow
schacon
152
7.2k

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