web-dev-qa-db-ja.com

継続的な「プラットフォーム」統合?

ある程度十分に文書化されたプロジェクトの大規模なコードベースを蓄積しており、その多くは積極的に使用されていませんが、必要に応じてすぐに再び使用できるようにしたいと考えています。

さまざまなプロジェクトをサポートする依存関係がアップグレードされたときに、これらのプロジェクトが動作状態にあることを自動的に確認するための最良の方法は何ですか?

これらの依存関係は、OpenCVやFFMPEGなど、大規模なオープンソースおよび外部の傾向があります。

連続するバージョン間で、コンパイル中に最近廃止された関数の使用に関する警告が表示されます。ただし、いくつかのバージョンよりもジャンプすると、更新は非常に困難な作業になります。

4
Eagle

本全体専用継続的デリバリー の概念があります。 (実際、私のAmazon検索では、いくつかあることがわかりました。アイデアは非常に単純です。ターゲットのデプロイメント環境に厳密に一致するテスト環境を作成します(仮想化を使用すると、これはそれほど困難な作業ではなくなります)。その環境内でビルドします。ビルドが検証されたら、その環境の構成をキャプチャします。つまり、そのデプロイメント自体を成果物として扱います。

アプリケーションをデプロイする場所を完全に制御できる場合は、ジョブが完了し、テスト環境を本番環境に昇格させて、次のフェーズに進みます。

外部ユーザーが使用するアプリケーションを構築している場合、それはもう少し難しいです。 Linuxでは、aptとrpmを利用して、適切な依存関係を解消するパッケージを作成できます。したがって、最新のビルドがlibGTK 4.6に依存している場合(たとえば、libGTK 4.6があるかどうかはわかりません)、パッケージ内でそれを指定できます。

Windowsでは、物事は少しトリッキーになります。しかし、私がリンクした本では、これらのシナリオに対処するためのオプションについても説明しています。

0
Michael Brown