web-dev-qa-db-ja.com

共有ライブラリとMercurialを操作するための推奨される方法論

私はいくつかのZend PHPプロジェクトに協力している開発者の小さなチームで働いています。私たちはMercurialをアップストリームリポジトリのコレクションと一緒に使用し、集中型テストとヘルスレポートにはJenkinsを使用しています。共通クラスの共有ライブラリを実装するが、現在の環境でうまく機能するワークフローを見つけるのに苦労しています。

現在、各プロジェクトには次のような構造が含まれています。

- application        (project specific code)
- build              (temporary files generated by each build)
- library            (code used by multiple projects)
    - OurLibrary     (our company’s shared codebase)
    - Zend           (external libraries)
- tests              (test code specific to this project)

ライブラリフォルダーはテストから除外されているため、共有ライブラリに対してユニットテストを実行するためのプロジェクトを作成しました。この決定は主に、誤ってテストクラスをデプロイしないようにするために行われました。これは、自動ビルドプロセスの変更によって大幅に軽減できるものですが、ライブラリを軽量に保つことが望ましいと感じたためでもあります。

ライブラリはMercurialサブリポジトリとして各プロジェクトに含めています。つまり、ProjectAで作業している開発者からライブラリにプッシュされた変更は、ProjectBには自動的に反映されず（良好）、ライブラリテストプロジェクトにも反映されず（不良）、Jenkinsは自動的に潜在的なコードの破損を警告しません。ライブラリ（非常に悪い）。

理想的な状況は、開発者が任意のプロジェクトからライブラリへの変更をコミットでき、自動化ツールが最新のライブラリコードに対して最新のライブラリテストを実行することです。さらに、開発者が新しいバージョンのライブラリテストをプルしたときにバージョンの競合が発生することはありません。

この種のワークフローの確立された方法論はありますか、それとも、サブリポジトリに完全にコミットする前に、作業慣行の構造を少し異なる方法で検討する必要がありますか？

phpmercurialworkflowsdevelopment-methodologiesjenkins
7
shanethehat

もし私だったら、他のように 'OurLibrary'プロジェクトをセットアップしただけです。つまり、テストを含む単一のプロジェクトとして。

プロジェクトのテストを他のプロジェクトに公開することがどのように問題になるかはわかりません。テストはドキュメントの一部であるため、実際にそれが良いことだと主張します。

reallyが何らかの理由で不可能である場合、考慮すべき別のオプションは、プロジェクトに「OurLibrary」のコンパイル済みバージョンを使用させることです。ただし、これにはそれ自体にいくつかの欠点があります。ライブラリのコンパイルされたバージョンを管理する必要があります。 「OurLibrary」コードプロジェクトを他のプロジェクトから直接編集できない。等.

2
vaughandroid

最後の手段

サブリポジトリは lastリゾート の機能と見なされることを考慮してください。

これは本質的に、正当な理由がない限り正当な理由がない限り、サブリポジトリを使用してはならないことを意味します。

いつ？

私はサブレポについていくつかの経験則を持っているので、次の場合にのみ使用します。

  • 私はすでにスタンドアロンレポとしてサブレポを持っています（つまり、私がインキュベートしているライブラリではありません）[〜＃〜] and [〜＃〜]
  • （それは私が所有するコードです[〜＃〜]または[〜＃〜]サブレポのコードは積極的に開発されています）[〜＃〜]および[〜＃〜]
  • コードの更新は簡単ではありません[〜＃〜] and [〜＃〜]
  • （subrepoコードを編集してプッシュバックする可能性がある状況があります[〜＃〜]または[〜＃〜]fork新しいプロジェクト固有のsubrepoコードを使用し、そのリポジトリの最新の変更をプルして統合することができます（緊急事態や期限に柔軟に対応できます）。

最後の理由...

構成管理 ：何のどのバージョンが何のどのバージョンと共存しているかを追跡する場合、そして最も重要なこととして、私は欲しいこれらを制御します。

たとえば、「OurLibrary」の最新の開発/実験ブランチを現在のプロジェクトの本番コードに対してテストするとします。この状況でサブレポがあると非常に便利です。

自分に質問し続けます

サブレポを使用するアイデアに慣れるかもしれません。しないでください。 「サブレポを使用すべきでないのはいつですか？」と自問し続けてください。理由がわからない場合は、使用しないでください。

リラックス

サブレポを使用しなかったとしましょう。理由Xはいつでも修正できるためです。いずれにしても、現在のプロジェクトのサブレポ履歴は必要ありません。

サブレポが0日以降になっているはずのファイルを削除したいという極端なケースでは、 ConvertExtension を使用しますファイルマップファイルでサブレポを抽出します。

これはお勧めしません（メインプロジェクトが目的のサブレポの親である場合）。ただし、コンポーネントとメインプロジェクト間のバージョンを処理するための新しい親レポが存在する構成管理の使用例には役立ちます。それらの1つです（必要なサブレポと同じレベル）。例：

project (repo)
|-component1
|-component2
|-component3

になる

project (new-repo)
|-component1 (subrepo)
|-component2 (subrepo)
|-component3 (subrepo)

それ以外の場合：

project (repo)
|-app
|-lib
|--|-libA
|--|-libB

に変わる

project (repo)
|-app
|-lib
|--|-libA (subrepo)
|--|-libB

.hgsubエントリを作成するまで、libAが存在しない履歴に穴が残ります。

2
dukeofgaming