Tomas Holmberg
最新の開発手法は、アジャイル、スクラム、CI/CD、DevOpsなど、進化し続けています。多くの場合、より良い品質でより迅速に開発することを目的としています。スピードは、新しいアプリケーションの開発速度や、バグを発見した後にどれだけ早くアップデート版をリリースできるかなどで測ることができます。品質には安全性が含まれますが、企業によっては別の意味になる場合もあります。「Develop Once, Deploy Anywhere（一度きりの開発で、どこにでもデプロイ）」という考え方は、デプロイされる対象とは無関係に同じアプリケーションを2度書くことを避けることで、無駄を省くことに焦点を当てています。
開発工数を最小限に抑え、ほぼすべての製品で動作するようにするというコンセプトは、新しいものではありません。「Write Once, Run Anywhere（一度〔プログラムを〕書けば、どこでも実行できる）」は1995年にすでに確立されており、クロスプラットフォームのコードを作るために、Javaが使用されていました。
「Build Once、Deploy Anywhere（一度きりのビルドで、どこでもデプロイ）」についての議論もあり、Anywhere（どこでも）が Everywhere（どこにでも）に置き換えられることもありますが、コンセプトは同じです。Build Onceは、しばしば再構築を必要としないものを作ることを指します。その場合、コンテナなどのテクノロジーは、多くのシステムで実行され、外部ライブラリに依存しないマイクロサービスを作成することで役立ちます。コンテナは依然としてカーネルに依存していますが、これは重要なことではありません。
一度きりのビルド
なぜ一度しかビルドしない方がいいのか？開発者は、アプリケーションのリリース候補をターゲット環境にデプロイするために、ビルドボタンを押すわけではありません。その作業を管理する自動ビルドとテストの自動化システムがあります。したがって、もはや「一度きりのビルド」は重要ではありません。
一度きりのビルドには、根本的な問題があります。アプリケーションがアップグレードやバグ修正が必要ないと、どうして分かるのでしょうか？完璧なアプリケーションを作成したとしても、それはビルドに使用されるツールチェーンや、動的または静的にリンクされたライブラリに依存しています。コンパイラにバグがあり、アプリケーションが安全でない場合はどうなるのでしょうか？アプリケーションが依存しているライブラリにバグがあるとどうなるでしょうか？ライブラリは他のライブラリに依存していることが多いため、アプリケーションにバグがないと言い切ることは困難です。完成品はもはや完璧ではなく、最終的にアプリケーションを更新する必要があるかもしれません。
一度きりの開発
Develop Once（一度きりの開発）は、コード、コンフィグレーションスクリプト、宣言的な仕様など、何かを開発することを目的としています。最終的に出来上がるものがコンテナであろうと、アプリケーションであろうと、重要ではありません。ユースケースに応じて、同じ開発アーティファクトを使用して、デプロイされる場所に最適なデリバリーをすることができます。
完成品の再構築は、依存関係にある部品のバグ修正によって引き起こされる可能性があります。設定の小さな変更でも、中間バグを誘発する可能性があります。
LinuxディストリビューションビルダーであるYocto Projectは、デプロイ方法やデプロイ先を定義せずにコードを開発することを可能にした良い例です。開発者は、1つまたは複数のレシピでレイヤーを定義します。レシピには、アプリケーションを構築するために必要なすべての情報が含まれています。開発者は、後でコードを書き直す必要がないように、できるだけ適切なコードを作成しなければなりません。
コードの書き直しを防ぐさまざまな方法があります。重要な要素の1つは、できるだけ短いコードを書くことです。ゼロ行のコードはバグもゼロです。1つの方法は、コードが高度にモジュール化されていることを確認することです。各パーツの目的は1つだけです。コードをその機能に合わせて最適化すれば、コード量も制限されます。
プログラミング言語も書き直しを防ぐのに有効です。高レベルの宣言型プログラミング言語でコードを書くと、最小限のコード量になります。ライブラリやツールは、そのコードを機械語に解析します。バグは、切り取った元のコードには存在しませんが、依存しているものの中にはまだバグが残っている可能性があります。もう一つの方法は、Rustのようなメモリセーフな言語を使用することで、アプリケーションがメモリセーフであることを確認することができます。
どこでもデプロイ
Deploy Anywhere（どこでもデプロイ）は、アプリケーションをどこにでもデプロイできることを意味します。どこでもというのは、見方によってさまざまな意味があります。ある人は、どこでもとはLinuxが動作する古典的なx86システムのことだと思うかもしれません。しかし、より広い意味では、大きなサーバーから小さな組込みデバイスまで、あらゆるハードウェアアーキテクチャとあらゆるサイズのシステムを指します。
アーティファクトを作成するためのツールは多数ありますが、それらは多くの場合、特定の種類のほとんどのハードウェアで動作するように構築されたビルド済みのイメージとライブラリに依存しています。Yoctoとは対照的に、結果は特定のハードウェアの機能に対して最適化されていません。
Yoctoビルドシステムは、アプリケーションのビルドと、パッケージングやデプロイ可能なアーティファクトの作成を区別しています。ビルドシステムは、deb、rpm、またはipmパッケージを作成し、直接デプロイするか、他の伝達手段を介してデプロイすることができます。ビルド システムは、いくつかのイメージタイプ、SDK、システムコンテナー、またはアプリケーションコンテナーを生成することができます。Yoctoには標準的なレシピが含まれており、新しいデプロイメントを実行するための独自のレシピを書くことができます。その結果は、無駄のない Linuxインストールを実行するだけの小さなARM組込みデバイスから、クラウド内の本格的なKubernetesシステムまで、あらゆるものにデプロイされます。
まとめ
ソフトウェアの開発は大変な作業です。高レベルのアプリケーションを構築し、ビルド、パッケージ、デプロイをツールに任せることで、アジリティとスピードを得ることができます。Yoctoは、開発と最終アーティファクトの作成を分離することで、開発者がこの目標を達成することを支援し、アーキテクチャに依存しない特定のデプロイに最適化します。開発者は、最終アーティファクトを気にすることなく、アプリケーションの開発に集中することができます。