はじめに

こんにちは、西日本テクノロジー＆イノベーション室の田中です。 私は2020年の2月頃からNablarchの開発にかかわっています。

Nablarchは、使い方や機能を紹介する記事は多くあります。一方で、Nablarch自体がどのようにして作られているかを解説している記事はあまりありません。 そこで今回は、私の半年間の経験を元に、フレームワークとして使われているNablarchがどのようにして開発されているかについてご紹介します。

Nablarchとは

Nablarchは、TISで開発しているOSSのJavaアプリケーション開発/実行基盤です。 TISで開発している多くのエンタープライズシステムで採用されています。

詳しくは弊社のNablarchの紹介ページをご参照ください。

開発の流れ

対応方針の検討

Nablarchの修正は、主にNablarchを利用しているプロジェクトからの改善要望や不具合の報告を受けて行われます。 もしくは、システム開発の潮流に合わせるための改修（例：クラウド環境でNablarchを使いやすくするための改修）なども行われたりします。

いずれにせよ、まずはどのようにしてNablarchに修正を入れるか、対応方針を検討します。

Nablarchはエンタープライズシステムで安心して使っていただけるように、後方互換性の維持に特に重点を置いています。 バージョンを上げることでこれまで動いていたコードが動かなくなってしまっては、安心して利用することはできません。 したがって、修正の方針は既存の動作に影響を与えないように細心の注意を払って検討します。

また、サードパーティのライブラリを使用した機能を追加する場合は、そのライブラリの仕組みや使い方を調査します。 そして、どのようにNablarchに組み込むかを検討します。

検討した結果は、Nablarchの開発に長く携わっている有識者の方にレビューしてもらい、問題がないことをチェックします。 レビューでOKをもらったら、いよいよ実装に着手します。

ソースコードはGitHubで管理

Nablarchは、すべてのソースコードをGitHubで管理しています。

Nablarchは、大きく次の３つのブランチを使って開発を行っています。

  • master ブランチ
    • 現在リリースされている最新状態のブランチ
  • develop ブランチ
    • 次のリリースに入れる予定の修正が入った開発ブランチ
  • feature ブランチ
    • 個々の機能修正を行うための作業用ブランチ

開発を始めるときは、まず develop ブランチから feature ブランチを作成します。 そして、 feature ブランチで修正をコミットしていきます。 開発が完了したらGitHubにプッシュして、 develop ブランチに対してプルリクエストを作成します。

プルリクエストの内容は他の開発メンバーにレビューしてもらいます。 レビューが通ると、晴れて develop ブランチにマージされ、次期リリースに組み込まれます。

公開ドキュメントの修正

Nablarchには、仕組みや使い方を詳しく解説した公開ドキュメントがあります。

機能を追加したり修正した場合は、この公開ドキュメントも合わせて修正する必要があります。

このドキュメントは reStructuredText と呼ばれるマークアップ言語で書かれています。 また、HTMLへの変換には Sphinx というPython製のツールを使用しています。

このドキュメントも、ソースはGitHubで管理しています。

公開ドキュメントの修正も、他のソースコードと同じ要領で行います。 つまり、 develop ブランチから feature ブランチを作成して修正をコミットし、プルリクエストを出してレビューをしてもらいます。 develop にマージされれば、次のリリースで公開されるようになります。

テスト

最後に、テストについて紹介します。

NablarchのユニットテストはJUnitで作成しています。 機能追加や修正をした場合は、手を入れた部分をテストするようにJUnitのコードを変更します。

Nablarchの開発では Concourse CI というCI/CDツールを導入しています。 あるモジュールの develop ブランチに修正がマージされると、そのモジュールのユニットテストが自動的に実行されます。 そして、そのモジュールに依存する他のモジュールも自動的にユニットテストが実行されていくようになっています。

下図は、実際のConcourse CIのパイプラインの様子です。

もしテストが失敗した場合は、Slackに下図のようなテスト失敗の通知が来るようになっています。

Concourse CIでテストを実行するときは、カバレッジの集計と静的解析も行っています。 収集された情報は SonarQube に送られ、下図のように画面で結果を確認できるようになっています。

この結果は、テストケースやソースコードの品質に問題が無いかを確認するための目安の１つとして利用されています。

またJUnitによる自動テスト以外にも、Nablarchを使ったアプリケーションに修正した機能を実際に組み込んで検証する手動テストも行います。

手動テストは、主にNablarchのExampleアプリを使用して行います。 Exampleアプリとは、Nablarchが提供する機能の実装例を示すために用意されているもので、ウェブやバッチなど様々なExampleアプリが用意されています。

例えば、ウェブ機能の修正であれば nablarch-example-web を、バッチ機能の修正であれば nablarch-example-batch を使って手動テストを行います。

さらに、アプリケーションの性能に影響を与えることが懸念される修正の場合は、品質を保証するために性能テストも実施します。 私が経験したものとしては、新規開発した機能を nablarch-example-web に追加し、大量のリクエストを送って性能に問題がないことを確認するというテストがありました。 このとき、リクエストの送信には Apache JMeter を使用しました。

まとめ

Nablarchは、後方互換を維持するために慎重に修正内容が検討されて開発されています。 また、品質を保証するためにConcourse CIによるユニットテストの自動実行、Exampleアプリを利用した手動テスト、そして必要に応じて性能テストが実施されています。 ソースコードはGitHubで公開されているので、簡単にご覧いただくことができます。

以上が、Nablarchの開発がどのように行われているかのご紹介でした。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。