11

現在、他部署が開発したフレームワークをベースに開発するプロジェクトに携わっています。私たちは現在、私たちの部門で品質基準を導入しています (ついに、やった!) が、それらを他の部門に導入することは現在不可能です. その結果、API の安定性も安定版リリースもなしに、絶え間なく変化するターゲットに対して取り組んでおり、少なくともストレスがたまっています。

私たちは最初に問題を修正しようとしているので、「アップストリーム」別名フレームワーク コードの変更に対して可能な限り自分自身を保護したいと考えています。ハード モジュールの依存関係を想定していました。

  1. コードで定義されたフレームワーク モジュールの特定のバージョン範囲のみを使用します。
  2. 単体テスト チェックを使用して、必要なすべてのバージョンがまだ利用可能であることを確認します。
  3. フレームワーク コードのピア レビューを必要とするすべてのバージョン範囲の拡張。

それが今のところの計画です。今質問：

  1. それは賢明ですか？そうでない場合、他のアイデアはありますか？
  2. これをperlでどのように実装しますか? を使用use Moduleすると、動作するはずの最も低いバージョン コードのみを定義できます。
4

7 に答える 7

15

これは非常に賢明な計画であり、私はこれを「DPAN」と呼んでいるプライベートCPANのようなリポジトリを介して実装します。実際のCPAN（またはBackPAN）から必要なディストリビューションとバージョンを選択し、そこから独自のリポジトリを作成します。CPANクライアントはこのリポジトリのみをポイントし、バージョンを必要なものに効果的にフリーズします。必要な場合にのみアップグレードします。

さらに、DPANを使用すると、独自のローカルのプライベートコードを簡単に追加できるだけでなく、サードパーティのパッケージを変更してインストールの問題などを修正できます。PerlReviewの2009年夏号のアイデアは完全に正当化されます。。YAPC::RussiaでのCreatingYourOwnCPANトークのスライドもご覧いただけます。

この種のソリューションに興味がある場合は、MyCPAN :: App::DPANモジュールを確認してください。ディストリビューションのディレクトリを取得し、残りはあなたに代わって行います。あなたはあなたのCPANクライアントをそれに向けます（そしてそれがインターネットに接続しないことを確認します）そしてそれはそれです。

独自のリポジトリを作成できたら、テストリポジトリを簡単に作成できます。アップグレードしたいと思うバージョンをダンプし、テストサーバーにコードをデプロイして、結果を収集します。結果が気に入らない場合は、リポジトリを簡単に変更できます。

私のDPAN作業の次の大きなステップは、インストールした可能性のあるモジュールを含む既存のPerlインストールを取得し、そのインストール状態を提供するリポジトリを作成することです。私は仕事をするために必要なすべての主要な部分を持っていますが、私は最初の部分で数人の顧客を実行させるのに少し忙しかったです。

このことについてもっと知りたい場合は、私に知らせてください。:)

于 2009-07-31T17:20:29.640 に答える
4

PARを見てください。一連の依存関係を 1 つのファイルにまとめることができます。彼らがリリースしたモジュールを取得してPARファイルに入れ、変更を受け入れたい場合にのみPARファイルをアップグレードできます。

于 2009-07-31T17:26:40.067 に答える
2

これについては、コードが依存するライブラリのプライベートコピーを作成し、libマイルストーンに達したときに新しいバージョンを定期的にチェックアウトする場合を除いて、これらのコピーを変更しないことを理解した上で、プロジェクトのディレクトリに配置します。

于 2009-07-31T17:15:33.317 に答える
2

CPAN があなたが依存しているモジュールよりも安定していることを願っていますが、同様の質問をさせてください: CPAN モジュールの予期しない変更からどのように身を守るでしょうか?

1 つの答え: モジュールをダウンロードし、テスト環境でそれに対してコードをリグレッションします。

ここで同じものを使用できますか？モジュールの「ライブ」コピーを指す必要がありますか、それとも独自のコピーを指すことができますか?

于 2009-07-31T17:11:56.787 に答える
2

Cartonはあなたが探しているものだと思います (perl のバンドラー)。plenvと組み合わせるとうまくいくと思います。

于 2015-02-11T06:24:48.947 に答える
1

誰かがすでにPARを指摘しました。PAR::Repositoryについて言及させてください。これは、コンパニオン モジュールPAR::Repository::Clientです。それらは、ローカルで見つからない (またはサーバーのパッケージを優先することさえできる) 依存関係を自動的にロードできるクライアント/サーバー インフラストラクチャを実装します。管理者は、リポジトリにパッケージを追加したり、リポジトリからパッケージを削除したりできます。パッケージの実際の提供は、まったく通常のサーバーで行われます。任意の http(s) サーバーまたは単に file:// で十分です。他のプロトコルは、実装が比較的簡単です。

前述の魔法の自動読み込みメカニズム、パッケージのインストール、および自動パッケージのアップグレードを備えています。モジュールのドキュメントとは別に、これをある程度カバーするYAPC::Europe 2008 の PAR に関するプレゼンテーションを見ることができます。

自動アップグレードは十分に高度な技術であることを認めなければなりません。かじる子猫がすべてなくなると、赤ちゃんを 1 つか 2 匹食べる可能性があります。

于 2009-08-01T08:49:13.280 に答える
-1

外部モジュールのバージョンを確認したい場合は、(少なくともそれらが $VERSION を適切に報告する場合) 次のようなものを使用できます。

BEGIN {
    use foo;
    use bar;

    die "Ghaaaa" if $foo::VERSION < 2.1;
    die "Aaaargh" if $foo::VERSION > 3.12;
}
于 2009-07-31T17:27:03.933 に答える