web-dev-qa-db-ja.com

アプリケーションでmonorepoのバージョンを管理するには、複数のリリースをサポートする必要がありますか？

パッケージの1つが複数のリリースをサポートする必要のあるアプリケーションである場合、monorepoでバージョンを管理する方法を理解しようとしています。

たった2つのパッケージ（libとapp）のmonorepoがあるとします。

_repo:
- [email protected]
- [email protected] (depends on [email protected])
_

_[email protected]_がリリースされました_release-app-1.0_タグが作成されました。

コードの変更を続け、リポジトリは次のようになります。

_repo:
- [email protected]
- [email protected] (depends on [email protected])
_

これで、顧客は_[email protected]_のコードに起因する_[email protected]_のバグを発見しました。

このバグはどこで修正すればよいですか？

理想的には、libは現在_2.1_にあるため、masterのバグを修正して_[email protected]_を解放し、_[email protected]_を更新して_[email protected]_を使用する必要があります。

しかし実際には、いくつかの課題があります。

  1. _release-app-1.0_を最初にチェックアウトして、_[email protected]_がlibに修正を実装できるかどうかを判断するために、SemVer互換のmasterを使用していることを確認する必要があります。
  2. masterに変更を加えて_[email protected]_を解放したら、それらすべての変更を_release-app-1.0_にバックポートする必要がありますか（および方法）。 libから_release-app-1.0_へのmasterにのみ関連するすべての変更を選択することはほぼ不可能です。しかし、それを行わない場合、_[email protected]_を解放してタグ_release-app-1.0.1_を作成すると、appとlibの間のモノレポリンクが壊れます（_[email protected]_は_[email protected]_に依存します）。しかし、そのタグではlibはまだ_2.0_にあります）

一方、_[email protected]_を直接修正して_[email protected]_をリリースした場合、SemVerを使用するメリットはなく、_[email protected]_のすべての新機能/バグ修正を取得できます。

どんな提案も大歓迎です。ありがとう。

versioningrelease
2
unional

以前のバージョンに適用した修正を新しいバージョンで自動的に取得するこの問題の解決策はありません。

V2を修正してv2.0.1をリリースし、v2.1をリリース2.1.1を個別に修正する必要があります

ご存知のように、v2.1は内部的に完全にリファクタリングされています。 2.1を修正するために行ったコード変更は、2.1でもコンパイルされない可能性があります

チェリーピックは嘘です！

3
Ewan

影響を受ける最初のリリースでバグを修正する必要があります。この場合はrelease-app-1.0、libが2.0.1にぶつかります。この修正はmasterにマージまたはチェリーピックして、libを2.1.1にバンプすることができます。

1
Ozan

これは、他の人からアイデアを集めた後の私の考えです。

まず、monorepoの利点を説明しましょう。

  • パブリッシュチェーンの必要性を減らす：
    • package-a：変更して公開
    • package-b：package-aを更新、変更して公開
    • package-c：package-bを更新、変更して公開
    • ...等々
  • シンボリックリンクまたはソースコードへの直接参照（JavaScriptなどのスクリプト言語用）：
    • テストランナーが使用できる変更がすぐに利用可能

この質問では、Googleなどの超大規模リポジトリについては説明しません。たとえば、小規模から大規模のモノレポに焦点を当てます。

唯一の違いは、以前のリリースをかなりの期間（1〜3年）サポートする必要があることです。

同じ例を使用してみましょう：

repo:
- [email protected]
- [email protected] (depends on [email protected])

[email protected]をリリースする前は、基本的にはmasterという1つのブランチしかありません。 [email protected]、[email protected]、[email protected]のバージョンタグはすべてmasterの下にあります。

開発を続けると、レポは次のようになります。

repo:
- [email protected]
- [email protected] (depends on [email protected])

ここで、[email protected]および[email protected]のバージョンタグはトレンドを継続し、すべてのものがmasterの下で線形になり、次のようになります。

[email protected] ... [email protected] ... [email protected] ... [email protected] ... [email protected] (master, HEAD)

これでお客様の問題が発生します。 [email protected]タグをチェックして、問題が[email protected]内にあることを発見しました。これは[email protected]です。これは、[email protected]タグ以降、libにいくつかの変更が加えられる可能性があるためです（たとえば、日課の変更、バージョンバンプはトリガーされません）。

したがって、この時点で、2つのことを実行できます。

  1. libの問題を修正し、[email protected]として公開します
  2. masterをチェックアウトし、そこでバグを修正して、[email protected]として公開します

（1）の利点は、それが単純で、変更が最小限であるため、強力なテストスイートがない場合でも、このアプローチを実行できることです。ただし、欠点は、最新のlibに他のバグ修正がある場合、それらを取得できないことです（たとえば、新しいlibは実際には[email protected]）。

（2）を選択した場合、[email protected]のlib依存関係を[email protected]に更新する必要があります（"lib": "^2.1.1"を明示的に指定するか、ロックファイルに依存して最新バージョン）。

その後、monorepoを使用して利益を得ることができるように、[email protected]ブランチのlibパッケージを何らかの方法で更新する場合に問題が発生します。

意見が本当に分かれるところがあります：

a）更新しない場合、プロセスは古いリリースと個別のサイロをすべて処理し、monorepoがもたらすすべての利点を無視します。

これは、リリースが短期間である場合、および/または開発の利便性よりもワークフローのシンプルさを重視する場合、合理的なアプローチです。

b）アップデートする場合は、次のプロセスに従います。

  1. 最新のlibコードを[email protected]ブランチにチェリーピック（または直接コピー）して、コミットを実行します。
  2. libで必要な修正を実装し、コミット（およびオプションでバージョンをバンプしますが、タグは付けません）しますが、公開しません。
  3. libからmasterに加えた変更を選択し、[email protected]バージョンにタグを付けて公開します
  4. 公開[email protected]

ステップ3と4を入れ替えて、ワークフローをより簡単にすることができます。これは、論理的推論のためにこのようにリストされています。

[email protected]のバージョンタグは、[email protected]ブランチの下ではなくmasterで作成されるため、バージョンの追跡と履歴を維持しやすくなっています。

0
unional