クラウドでオープンソースソフトウェアを開発してイノベーションを高める方法

企業は、独自のクラウド プラットフォーム上でオープン ソース ソフトウェアを使用してアプリケーションを開発し、イノベーションに追加費用をかけずにイノベーション能力を向上させることができます。

ほとんどの企業において、最も大きなコストは人的資源です。しかし、オープンソース ソフトウェアを賢く活用することで、GitHub のユーザー ベースが企業のために「無料で」作業できるようになるため、コストを大幅に削減できます。しかし、GitHub には 6,500 万の登録ユーザー アカウントがあり、そのメンバーのほとんどが開発者であると想定する必要があります。 GitHub を中心に巧みに構築すれば、これらの開発者は実際に会社の人材となり、Amazon、Facebook、Microsoft などの大企業よりもはるかに効率的になり、コストを大幅に削減できます。まず、解決策を理解できるように問題を述べましょう。

[[412034]]

質問

ある上級開発者は、自分が勤めていた会社で、誰かがオープンソースの Git リポジトリをクローンし、そのコードを会社のプライベート エンタープライズ クラウド Git リポジトリに追加し、そのリポジトリに変更を加えたという事例があったと述べています。 2 年後、同社の開発者は GitHub 上の他の開発者が作成した最新バージョンを使用するために 6 週間を費やし、その過程で可能な限り多くのカスタム機能を維持しようと努めました。業界の専門家は、コードの品質は自社の責任であるため、コードの品質を低下させる可能性があるこの慣行に同意していません。

可能であれば、彼が「Gitless Cloud Pipelines」と呼ぶものを使用する方がはるかに良いでしょう。つまり、オープンソース プロジェクトで作業する場合、通常は独自の git リポジトリを作成せず、オープンソースの git リポジトリに直接リンクします。その結果、メインのオープンソース メンテナーが新しいオープンソース バージョンをリリースした場合、新しいオープンソース バージョンはメインのオープンソース メンテナーによってリリースされるため、ソフトウェアを更新したいときはいつでも、オープンソース リポジトリからプルして変更することができます。これにより、オープンソース ソフトウェアを企業内から活用できるようになり、開発者は企業にコストをかけずに独自のソフトウェアを継続的に改善できるようになります。

後部

日々の仕事でどのように Magic を使用しているかを示すこの開発者を見てみましょう。重要なポイントは、彼が Magic をクローンしたのではなく、Magic の GitHub リポジトリを直接参照する Azure パイプラインを作成し、「ソースの取得」セクションにいくつかの異常があることに気づいたことです。

ソース コードが Azure リポジトリではなく GitHub を指していることに注意してください。上記のスクリーンショットでは、マスター ブランチを直接指定しています。実際の運用環境では、プロジェクトのメンテナーと非常に密接な関係がない限り、特定のタグを指定する方がよいでしょう。単純に言えば、「マスター」ブランチであっても、一時的なコミットが含まれている可能性があるからです。タグは基本的に、プロジェクトの新しいバージョンが作成された時に作成されます。これにより、ランダムなマスターコミットよりもプロジェクトの安定した状態がより確実に保証されます。

この開発者は Magic の主任メンテナーであるため、Magic に精通しており、特定の時点で現在の「マスター」ブランチがどの程度優れているかについてかなりよく理解しています。さらに、マスター ブランチにコミットされたすべての変更に対してプロジェクトをビルドするために、パイプラインの CI トリガーをオフにしました。最後の部分は非常に重要です。特に実稼働環境では、ランダムなコミットによって新しいビルドがトリガーされることは望ましくないからです。これにより、パイプラインは CI トリガーを使用するのではなく手動でトリガーする必要があるため、プロセスの自動化は低下しますが、オープンソース リポジトリから新しいビルドが作成されるタイミングを 100% 制御することもできます。

その後、パイプラインは Babel と Babelfish をクローンします。これらのヒントを使用すると、特定の最終結果に必要な Magic マイクロサービスをモジュール フォルダーに追加できます。

これにより、モジュールをパイプラインの統合された一部として Magic バックエンドに動的にインストールできるようになります。

この特定のパイプラインでは、Magic の Windows 自動認証を有効にする必要がありましたが、これは、バックエンドを構築する前に NuGet パッケージをコアに追加するだけで簡単に実行できました。

これにより、特定のパイプラインを必要とする C# バインディングであるスロットを Magic バックエンドに動的に設定できるようになります。 Magic のモジュール性により、コードを変更することなく Magic の動作が実際に変更されます。

バックエンドをデプロイした後、変数置換を適用する必要があります。これは、メインのデプロイ アクションで JSON 変数置換を有効にし、パイプラインの変数セクションで置換する変数を参照するだけで簡単に実行できます。

セキュリティ上の理由から、それらの値は表示できませんが、バックエンドがデプロイされると、関連する「appsettings.json」値が動的に交換されることに注意してください。

フロントエンド

フロントエンドは同様のメカニズムを使用して構築されており、Angular プロジェクトには、プロダクション ビルドを作成するために参照できる npmrun-script セクションがあります。

確かに、Angular はビルド プロセス中にすべてをランダムに生成されたファイルにパッケージ化するため、フロント エンドは少し乱雑です。そのため、コード内でこれを調整しない限り、ここで変数をインテリジェントに参照することは困難です。したがって、簡単にするために、ビルド パイプラインの段階で変数の置換が適用されます。当然ながら、各環境で変数をオーバーライドする必要があると仮定すると、変数は環境ごとに構築する必要があるため、柔軟性が低下します。しかし、それはこの特定のプロジェクトにとって大きな問題ではありませんでした。

代替メカニズムも可能ですが、これには、Angular コードに奇妙な #{xxx} セクションが散らばることになり、最初に大量の無駄な構成値を変更しないと、そのままではデバッグ/開発環境で使用できなくなります。したがって、Magic の「環境ごとに 1 つのビルド パイプライン」という追加の要件は、開発環境で動作させるための開発依存関係や構成要件を一切持たずに、すべてを可能な限り汎用的に保つことができることを考えると、それほど高い代償ではありません。

基本的に、これはバックエンドの URL という 1 つの変数を置き換えるだけです。もちろん、これはバックエンド変数を使用するのと同様の方法で作成できますが、デプロイ ステップではなくビルド ステップで実行されます。

適切と思われる方法で展開することもできます。日常業務の開発環境では、仮想マシン上の IIS サーバーを使用します。これにより、1 台のマシンに 30/50 の Web アプリケーションを展開できるため、コストが大幅に削減されます。もちろん、Azure WebApps などの他のアプリケーションを検討することもできます。

「スマート」な部分

オープンソースの GitHub リポジトリを直接ポイントするこのような「Gitless クラウド システム」を作成することで、変更を手動でマージすることなく、プロジェクトに追加されたあらゆるイノベーションを継続的に活用できます。

ただし、すべてのプロジェクトがこのアプローチを使用できるわけではありません。たとえば、構成設定などによって動作をオーバーライドできない環境で動作するためにコードの変更が必要な場合や、追加機能が必要な場合、Magic のように動的な機能を動的に挿入できるプラグイン アーキテクチャが提供されていない場合などです。したがって、プロジェクトのコア アーキテクチャは「超アジャイル」である必要があり、必要なあらゆる手段を傍受してコアに追加できるようにする必要があります。 Magic ほど本質的に「アジャイル」な GitHub プロジェクトはほとんどないため、これは難しい場合があります。

コア プロジェクトに対するすべての制御を放棄すると、柔軟性とプラグイン アーキテクチャを備えた Magic のようなプロジェクトではあまり意味がない可能性があります。ただし、独自の Git リポジトリにソース コードがあるプロジェクトを制御するのと同じ方法でプロジェクトを「制御」することはできなくなります。ただし、GitHub プロジェクトの開発者やメンテナーのほとんどは、提示された変更要求を喜んで受け入れます。

あるいは、プロジェクトの開発者にインセンティブを与えてプロジェクト開発をスピードアップさせ、メンテナーに問題の優先順位をつけさせることもできます。企業が 6,500 万人の開発者とそのイノベーションのすべてを無料で利用できるのであれば、プロジェクトで開発者と企業の間に共生関係を築くことは、わずかなコストでより多くのイノベーションを導入する方法となる可能性があります。