はじめに
ビットキーで bitkey platform を開発している @otakakot です。
ビットキーはスマートロックを中心にソフトウェアからハードウェアにまたがりプロダクトやサービスを展開しています。そんな様々なプロダクトにおいて認証認可およびスマートロックのデジタルキー管理という中核を担う bitkey platform が存在します。bitkey platform はビットキーにおける解錠体験に大きく関わっており、リリースによるデグレーションは全サービスへと影響を及ぼします。このチームは QA 担当者などがいない状態で、テスト自動化を駆使して毎週リリースを実現しています。また、このテストは Jupyter Notebook を利用し管理・実行を行なっています。そんな自動テストを実現するための環境づくりや仕組みについて本記事にて共有いたします。
Jupyter Notebook
Jupyter Notebook は Jupyter プロジェクトが提供する Web ブラウザ上で動作するオープンソースの対話型実行環境です。[1]
Jupyter Notebook はデータ分析や機械学習に利用されることが多いですが弊社では下記3つの利点を感じているのでシナリオテストの管理に活用しています。
- １つのノートブックにコードの実行やドキュメント作成などをまとめることができる
- セルにコードを記述し、実行結果をすぐに確認することができる
- ドキュメント作成では Markdown を使用することができる
シナリオテスト
bitkey platform は画面を持たず API をビットキーのサービスに対して提供しています。
「アカウントを作成する」や「スマートロックを設置して解錠する」といった様々なユースケースは複数の API を組み合わせて実現できます。
API に対してシナリオテストを実施・管理することで以下の効果があります。
- 新規機能開発時の動作確認
- リファクタリングやパフォーマンス改善実施時のデグレーションの検知
- API 利用者に対する実装方法の提示
Jupyter Notebook で実装するときの工夫
テストを構築する上で３つのリトライを行う仕組みを導入しています。
これはシナリオテストを実行する上で非同期にて処理を実施する箇所があるためです。
（ex: メールを使ったアカウント作成、実行時間がかかる顔特徴量の抽出 etc ...）
- セルごとにリトライを行う仕組み
- ファイルごとにリトライを行う仕組み
- 失敗したファイルを記録し最後に出力
シナリオテストの自動化
シナリオテストを自動で実行するためにテストファイル群を Python 実行環境とともに Dockerfile を用いてコンテナ化します。
GitHub Actions を活用してテストファイルを管理するリポジトリの main ブランチにマージされるとトリガーによりテスト実行コンテナをビルド & デリバリーしています。
シナリオテストを自動で実行する基盤としては Argo Workflows を採用しています。
Argo Workflows は Kubernetes 上でコンテナ化されたジョブを実行するための OSS です。
Kubernetes 同様 YAML ファイルにて manifest を作成しワークフローを管理します。
そこまで複雑なワークフローは構築していませんが、「失敗したファイルを記録し最後に出力」を取得しリトライを実施するように構築しています。
テスト実行環境
シナリオテストを実行する環境として３つ用意しています。
- ローカル環境（ 開発者の Mac ）
- 開発環境（ Google Cloud ）
- 本番ミラー環境 ( Google Cloud )
それぞれ管理方法および実施方法が異なるのでそれぞれ解説します。
ローカル環境 ( 開発者の Mac )
弊社では開発メンバーに MacBook が支給されます。
開発メンバーは各々 Docker Compose を用いて bitkey platform をローカル環境に構築することができます。
bitkey platform を起動した状態でローカル環境では2つの方法でテストが実行できます。
- Jupyter Notebook にて編集しながら実行
- CLI を使ってファイルを指定して実行
Jupyter Notebook にて編集しながら実行する場合は Jupyter Notebook のサーバーを起動しノートを編集しながら手元で動作確認をしていきます。
この方式は「新規機能開発時の動作確認」を行なった際に動かしながらテストを確認できるので役立ちます。また、Jupyter Notebook を使うとレスポンスに関しても簡単にログにて確認できるので途中経過の値を可視化することも可能です。
CLI にてファイルを指定して実行する場合は「Jupyter Notebook で実装するときの工夫」で説明したリトライが実行されるようにスクリプトに組み込まれています。
リトライの実装は retry[2] というライブラリを用いて構築しています。
この方式は「リファクタリングやパフォーマンス改善実施時のデグレーションの検知」を確認するときに主に利用します。
開発環境 ( Google Cloud )
弊社はサービスの運用に Google Cloud を活用しています。
開発用としてひとつのプロジェクトを用意してそこにデプロイを行なっています。
Argo CD を活用し main ブランチにマージが行われるたびに自動でデプロイが実施されます。
この環境において前述した Argo Workflows を導入しています。
Argo Workflows によって毎朝テストが実行されるように Cron Workflows [3] を設定しています。
Cron Workflows は毎朝定期実行するように設定しています。
このテストが成功すれば社内のステージング環境へとデプロイします。
Cron Workflows で設定したテストは手動でも実行することができます。
定期実行が失敗して修正を行なった場合、それがクラウド環境でも正しく実行されるか確認したい場合に活用しています。
本番ミラー環境 ( Google Cloud )
bitkey platform は一週間に一度リリースを実施しています。
リリース前日に最終確認として本番ミラー環境を構築しそこに対してシナリオテストを実施します。
このプロジェクトはコストを鑑みてコンピューティングリソースなどは停止しています。
そのためテストを行うためにゼロから環境を構築します。
GitHub Actions と Argo CD を組み合わせて自動で構築しています。
テストの自動化についてはまだできていないので手元の PC からミラー環境に対して実行しています。
自動化する選択肢はいくつかあると思いますが（開発環境同様 Argo Workflows を利用する、GitHub Actions にて実行する etc ...）そこまで困っていないので取り組んでいないです。
おわりに
bitkey platform が取り組む Jupyter Notebook を活用したテスト管理および自動化についてご紹介してみました。
こうした取り組みにより定期的なリリースを安定して行うことができています。
一方で課題も存在します。
シナリオテストは約400ファイルほど存在しテスト実行時間も約30分くらいかかるので困っています。
使われなくなった機能もありその保守のためにテストがあったりするのでそちらを精査していく必要があるのかなと考えています。
また、困ってはいないと言いつつ、ミラー環境での検証完全自動化はロマンがあります。
実現できたらまた知見を共有したいと思います。
これらの知見が誰かの役に立てば幸いです。
8日目の 株式会社ビットキー Advent Calendar 2024 は ysmt が担当します。
8日目の ソフトウェアテスト Advent Calendar 2024 は boroccoli さんです。
Discussion