本日の記事の内容は真面目です。
あえてこのように断り書きをしなければならないと感じるほど、ご存じのとおり、普段私が真面目な内容を取り上げることはほとんどありません。しかしこの記事では、素晴らしいNuxeoコンテンツサービスプラットフォーム（Amazing Nuxeo Content Services Platform[1]）の継続的な向上について、真面目にご説明するつもりです。
これには、品質保証（QA）プロセスと継続的インテグレーション（CI）プロセスという、Nuxeoが真剣に取り組んでいる分野に関する説明も含まれます。
この取り組みを真剣に進められるよう、真面目でない私の関与は最小限に抑えられており、開発者（フロントエンド開発者としてのバックエンド）、QAチーム、DevOps、システム管理者などのエンジニアリングチームがこの取り組みを担当しています。
つまり、私以外のNuxeoの全員が担当しているということであり、このプロセスがしっかりしたつくりとなっている理由もそこにあります。
Nuxeoのオープンキッチンアプローチの対象は、ソースコードにとどまりません。内部プロセスを含むあらゆる要素のオープンソース化が進められています。
Nuxeoでは、皆さんがすでにお使いであるか、まもなくお使いになる予定のこのパワフルで素晴らしい製品をどのように構築し、改善を加えているかを、日頃から完全に透明化しています[2]。このことを詳しく説明した QA/CI文書 を読むと、そこに記載されていることがすべて最新技術に関するものであることに気付きます。（文書内の出現順で）GitHub、Jenkins、Mavenや、複数のテストツール（単体テスト、機能テスト、性能テスト) の使用については、こちら で説明されています。
全体像
次の図はこれらのプロセスを要約したものです[3]。
この図は、私がこの記事で伝えたい要点、つまり、Nuxeo Platformの継続的ビルドの背景にあるコア原則を表しています。プラットフォームのどの部分にフォーカスを当てるかにもよりますが、この図では割愛されている詳細やサブプロセスがもちろん存在します。
たとえば、オプションのアドオン（Nuxeo Vision、デジタル署名など）を変更した場合の影響は、コアプラグイン（バックエンドデータベースストレージ向けプラグインなど）を変更した場合の影響と同じではありません。また、プロセスがこの図で表されている順番に従うとは限りません。たとえば、コードレビューやブレインストーミング、「再調整」は、プロセスのどの段階でも行われる可能性があります。
全体像の説明
それでは、Nuxeoの主要QAプロセスとCIプロセスについて以下にご説明します。
1.Nuxeo開発者がプラグイン（プラグインAとします）の専用ブランチで機能を追加するか、バグを修正します（誰もマスターブランチで直接作業することはしません）。プラットフォームは コンポーネントモデルアーキテクチャ上で構築されているため、すべての機能がプラグインであり、ソースコード全体に手を加える必要はありません。プラットフォーム開発者は、プラグイン（Nuxeo WebUI、Nuxeo S3 Storage、Nuxeo LiveConnect、Bulk Document Importerなど）を一度に一つずつ変更します。
2.開発者が変更点をローカルでテストし、満足のいく結果が得られた場合は、変更内容を [GitHub](https://github.com/nuxeo）にプッシュします。結果に満足できない場合は、設計作業に戻ります。
3.GitHubにプッシュされた後、Jenkinsサーバはフックを使用して、プラグインAが変更されたことを特定できます。Jenkinsが変更内容をプルします。
4.さらに、プラグインAを開発者のブランチで構築するようApache Mavenに指示します。つまり、構築とテストが必要となります。上の概略図では省略されている詳細やサブプロセスがからんでくるのは、まさにこの部分です。プラグインによっては、プラットフォームとプラグインのフルアセンブリに対する機能テストまたは性能テストに加え、すべての依存モジュールのビルドに対するトリガも開始される場合もあります。
5.プラグインの構築とNuxeoのJenkinsサーバでのテストが正常に完了したとします。個人所有のコンピュータではうまくいったのに、組織のコンピュータでは正常に機能しないという問題を避けるためには、「Nuxeoのサーバ」でテストを行うことが非常に重要です。テストが成功した今、開発者は、変更内容をマスターブランチにマージするためのプルリクエストをトリガできます。少なくとも2名の同僚開発者がコードをレビューし、変更内容を検証します。全員が変更内容に同意するまで、ステップ1～4が繰り返されます。
6.ここでは、開発者のブランチがマスターブランチにマージされ、2番目の大がかりな作業が始まります。
7.Mavenがプラグインをコンパイルしてマスターに組み込み、テストします。
8.何も問題がない場合は、プラグインがパッケージ化されます。
- 機能テスト、性能テスト、マトリクステストなどのすべての検証手順が開始されます。
10.何も問題がない場合は、プラグインがNuxeo Marketplaceに送られ、お客様向けに提供されます。お客様は独自の継続的インテグレーション/デプロイメントツールを使用して、プラグインを自動的に取得することができます。この自動化はいたって簡単で、「./nuxeoctl mp-install the-plugin-artifact-id」と入力するだけです。
また、ステップ9の後で、さまざまな手動テストサーバが継続的デプロイメントプロセスで更新されます。ここでは、Ansibleのスクリプトやコンテナなど、（私のようなスクリプトマニアにとって）わくわくするような最新の機能が使用されます。
また、おそらくお気づきのとおり、この図にはSonarが言及されています。Sonarは、コードの質とカバレッジをチェックする作業でNuxeoをサポートしています。マスターブランチが構築されると、SonarはGitHub上で変更を受け取って調整し、（開発者とレビュー担当者が見落とした可能性のある問題やカバレッジに関する）詳細情報をNuxeoに報告します。
このプロセスの追加情報
ここで言い忘れてならないのは、これらすべての処理が自動化されていることです。
いや、むしろ自動化されていて当然と言えるかもしれません。なぜならば、「GitHubからダウンロード」ボタンや「コンパイル」ボタン、「Sonarに報告」ボタンや「テストの実行」ボタンを押すための人員を雇いたい組織などいません。
ただし、公正を期して言うと、すべてのステップが完全に自動化されているわけではありません。たとえば、最初のステップでは、できる限り最善のコードを考え出し、それを記述するために、頭脳明晰な開発者の思考力が必要となります。
また、何か問題が起きた場合は、適切な人員に通知が届きます。プラグインをできるだけ早急に修正できるよう、開発者本人はもちろん、他の開発者や管理者も通知を受けます（Nuxeoがいかに風通しの良い企業であっても、エンジニアリング部門も含め上司・部下関係は存在するからです) 。
これらのプロセスを実行するため、AWS上のクラウドインフラストラクチャ内にあるDockerコンテナでJenkinsが起動されます（この処理は自動の場合とオンデマンドの場合があります) 。
この流れは、Nuxeoの公開QAサイトであるqa.nuxeo.com 。
今後の展望
冒頭で述べたとおり、構築対象のプラグインによっては、この記事の図には表されていない詳細やサブプロセスもからんできます。テスト＆プッシュと呼ばれるプロセスはその一つです。ここでは、プラットフォーム全体に影響する可能性のある変更を開発者が加えます。
たとえば、ある開発者がNuxeoによって使用されるJSONパーサーライブラリのバージョン変更を行っているとします。この変更はプラットフォーム全体に重大な影響を与える可能性があるため、単一プラグインをテストするだけでは不十分です。開発者は、プラットフォーム全体を構築してからプラットフォーム全体をテストする作業を伴う、テスト＆プッシュテストを実行する必要があります。プラットフォーム全体を構築してテストする作業は時間がかかり、大量のコンピューティングリソースを必要とします。そのため、このテストを自動的にトリガできる場合でも、大半の処理を手動のオンデマンドのままにしておきたいというのが（この記事の執筆時点での) 現状です。
Nuxeoチームは、どのようにすればプロセスをニーズに適応させ、改善できるかについて常に真剣に考えています。そこで考案されたのが、タスクをディスパッチできるようにすることです。Nuxeo Content Services Platform全体のテストには時間がかかります。なぜならば、テストとは本質的に逐次処理で（順番に）実行されるものであるからです。ただし、テストの大部分は互いに影響を及ぼしません。たとえば、nuxeo-platform-renditionsは、nuxeo-platform-tagのテストが完了するのを待つ必要がありません。そのためNuxeoでは、JenkinsパイプラインとDockerを利用することで、ひとかたまりになっているテスト＆プッシュを複数のテストとチェックに細分して、並列実行させたいと考えています。これにより、CIリソースが最適に利用されるようになると同時に、テスト結果を迅速に取得できるようになります。
まとめ
NuxeoはQAプロセスとCIプロセスを真剣にとらえています。
（簡潔な結論だと思いませんか？）
[1] ANCSPという頭字語は、私がこの記事のために考えた造語であり、マーケティングチームの承認を受けていません。
[2] 皆さんの中には、Nuxeoに関する情報を調べていて、この記事を見つけた方がいらっしゃるのではないでしょうか？導入を検討中の読者の方が世界No.1のコンテンツサービスプラットフォーム、Nuxeoを選択することを確信して、「まもなくお使いになる予定の」と書きました。
[3] 当初私は次のような超概略図を載せるつもりでした。
概略図の原案：
ところが、この図をNuxeoのCTO、Thierry Delpratに見せたところ、彼が私に向かって椅子を投げつけてきそうな気配を感じたので、もう少し情報を付け足すことにしました。CTOらしい反応ですね。