API結果差分確認ツールJumeauxのVersion1.0をリリースしました！

Table of Contents

はじめに

2015年にリポジトリを作成し、2017年から本格的に開発しはじめたツールが先日Version1.0になりました。
名前はJumeaux(ジュモー)です。

フランス語で『双子』という意味があります。

Jumeauxとは

Web APIに対し、2つのエンドポイントにリクエストして、レスポンスの差分を調べるツールです。
『似たレスポンスを比較する』という点が、Jumeaux(双子)という名前の由来です。

上記はデモです。文字が小さいので画面を最大化してご覧下さい。

特徴

2019-04-16時点の特徴です。

  • Python3.6,3.7対応
    • pipでCLIとしてインストールできる
  • テストケースとyamlの設定ファイルを記述
  • 結果の概要はjson形式などで出力される
  • アドオン機能
    • フローの合間に様々な処理を入れることができる
    • bundleされているアドオンは37
    • 必要ならばオリジナルアドオンを作成できる
  • レスポンスの任意パスプロパティに生じる差分に対し、条件に応じて無視できる
    • アドオンで対応している
  • 対応METHODはGETのみ
  • Miroirを使うとGUIツールで高度な確認ができる

詳しい情報はTopとQuickstartをご覧下さい。

Miroirについて

Miroirは2019-04-17現在、Version1.0に向けてドキュメントを整備中です。
今のところ、デモ動画や画面説明のページは存在しません。

MiroirのVersion1.0をリリースしたら、本記事とあわせてブログでお伝えする予定です。

※ 1年ちょっと前のスクリーンショットは以下の記事で載せています

開発を始めた経緯

仕事でWebAPIを扱う機会が多く、以下の問題を解決したかったからです。

リリース前にデグレをキャッチしたかった

単体テストやE2Eテストは行っていました。
しかし、メンテされずにテストケースが古くなると機能しなくなってしまうことが多々ありました。

単体テストが書けないほどレガシーなコードを安心してリプレイスしたかった

リプレイス案件ってありますよね。
そう.. ソースコード見た瞬間に逃げたくなるヤツです😅

そのような場合、『まず単体テストを作ろう！』ってなると思います。
しかし、あまりに複雑すぎて単体テストを導入できないケースが多いのではないでしょうか。

Jumeauxを使った解決案

Jumeauxを使うことで、先ほどの問題を以下のように解決できます。

  • 本番環境にリクエストされたログをベースにテストケースを作成
  • 作成したテストケースでJumeauxを実行

実際に利用されているリクエストで対応前後の差分を確認できるため、安心してリリースできます。

勿論、Jumeauxでリクエストする環境は本番ではありません。
本番同等環境 <==> (検証環境 or 開発環境)です。

良かったこと

期間で4年、実質2年強の開発をして色々な収穫がありました。

継続的に開発する仕組みを学べた

1人でプロダクトのメンテナンスをし続けることから、継続的に開発するコツを学びました。

  • 最小限の工数で
    • リリースする方法
    • リリース内容を必要な人に伝える方法
    • 品質を担保する方法
  • 有用なドキュメントを運用し続ける方法

当たり前のことですが、どれも非常に大切です。

例えば、はじめはJenkinsでリリースをしていましたが、途中からLocalでのリリースに切り替えました。
Jenkinsの環境変化に対応するコスト が Jenkinsによる自動化のコスト削減 を上回っていることに気付いたからです。

チーム開発の場合、皆の環境が異なるためJenkinsは有効です。
しかし、1人の場合は必ずしもそうとは限らないと思っています。

CIはTravis CIで行っているため、品質面での問題もありませんでした。

拡張性の高いツールを開発するための設計を学べた

Jumeauxはアドオン機能を採用しています。
それを実現するためのモジュール設計やスキーマ設計は非常に勉強になりました。

開発を進めていくに従い、WebpackやAnsibleといった著名packageの設計に近づいていくことを実感していました。
それらを参考に設計するのではなく、自ら考え試行錯誤した上でその設計に辿り着けたことは貴重な経験だと思っています。

※ 仕事ではそんな悠長な時間はありませんしね😛

品質をキープできた

最終的に以下の数値を達成できました。

  • カバレッジ80%以上
  • maintainability A

Jumeauxのコード行数は6000行程度ですが、maintainabilityを意識してきたからこそ行数が抑えられたと思っています。

フロントエンドからインフラまで通した開発を経験できた

JumeauxはCLIですが、Miroirと連携する場合はAWSを使います。
S3やDynamoDBの設計を行い、aws-sdkを通して開発する経験ができました。

サーバレスの構成だから、お財布に優しいのもJumeaux+Miroirの強みですね😉

関数型開発を助長するOwlMixinを作った

Pythonは関数型言語のような思想があまりありません。
しかし私は関数型の書き方がシンプルで好きだったため、そのように書きたいと思っていました。

『無いなら作ればいい.. たとえPythonicじゃなくても継続的開発する方が大事』

結果、OwlMixinというpackageを作りました。

主な特徴は3つです。

  • モデルを定義すれば、様々な形式(json, yml, csv.. etc)からデータオブジェクトに一発で相互変換できる
  • map,filterなどの関数型functionが使える
  • Javaのような多機能Enumが使える

Jumeauxがmaintainability Aをキープできたのは、間違い無くOwlMixinのおかげです。

OwlMixin開発でPythonのメタプログラミングを学べたことも非常に有意義でした。

RFCに少しだけ詳しくなった

  • 一般的なルールに従う必要がある
  • どのようなAPIにも救いの手を延べる必要がある

一見相反する2つの要件を満たす為、落としどころを探ることが多かったです。
その為にはRFCをしっかり理解する必要がありました。
特にレスポンスヘッダのcontent-typeについてはかなり理解が深まりました。

全ての仕様に対応しているわけではありませんが、仕事で使えるレベルの仕様は網羅したと思っています。

課題

パフォーマンスの考慮

Pythonは実行速度が遅い言語ではあります..が、それを加味してもパフォーマンスへの考慮が足りなかったです。

例えば、OwlMixinは全てが即時評価です。
遅延評価で実装しておけば、より幅の広い実装ができたと思っています。

2年前の私は遅延評価への意識が低かったですね😅

カバレッジの更なる向上

100%は非現実的なので、当面は90%を目指していきたいと思います。

リファクタリングだけに時間を割く余裕は無かったので、Version2.0をリリースする前にはやりたいですね。
ロガーの出力もアドオンによってバラツキがあるため、その辺も統一したいです。

総括

Jumeaux1.0のリリースをしたので、簡単な紹介と振り返りをしました。

1.0は1つの通過点です。
既に私の中では2.0へのロードマップがぼんやり決まっています。

REST APIが主流である内は今後もバージョンアップを続けて、より多くの方に使っていただきたいと思っています。

Everyone can develop with confidence .. Dreaming of such a world 😄