31

私たちのチームは、ほとんどの製品で共有されているコア CRUD 機能の git サブモジュールを試しました。また、いくつかの一般的なユーティリティに Nuget パッケージ (現在は自己ホスト型) をうまく使用しています。

私たちのコア機能は頻繁に変更されるため、サブモジュールを適切にコミットし続けることは、私たちが予想していたよりも面倒なことであることが証明されています。コア機能をサブモジュールから Nuget パッケージに移動することを検討していますが、パッケージの頻繁な更新が Nuget でさらに苦痛になるかどうか疑問に思っています。

アーキテクチャとプロセスにこのわずかに侵入的な変更を加える前に、他にどのような課題に遭遇する可能性があるかについて、経験とガイダンスを持っている人はいますか?

4

2 に答える 2

6

何でもそうですが、状況によります。コア モジュールへのすべてのコミットが CI パッケージを生成する別の CI パッケージ リポジトリの使用を検討しましたか?

NuGet はまだ SemVer を完全にサポートしていないため (プレリリース バージョン + ビルド番号など)、最大の課題はパッケージのバージョン管理です。

編集: nuget.org は、SemVer 2.0 パッケージ バージョンをサポートするようになりました。この仕様を参照してください: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

SemVer を適切に使用してください。通常、リリースされたバージョン番号は事前にわからないため、CI パッケージのバージョンは最新の安定版リリースから継続されます。CI パッケージ自体は、プレリリースと見なされます。

例: 2.2.0-CI201209140650(これは、2012 年 9 月 14 日の 06:50 に次の 2.2.0 リリース用に作成された CI ビルドです) <-- 注: このリリース バージョンは変更される可能性がありますが、常に更新パスが存在します。

SemVer v2.0.0 を採用する場合は、次の例を採用することもできます2.2.0-CI.2012.09.14.06.50。

重要な注意: nuget.org (および MyGet や VSTS などの他の NuGet サーバー/サービスの範囲内) は、ビルド メタデータのみが異なる複数のパッケージ バージョンをサポートしていません。

これは、これらの制約 (およびいくつかの適切な TeamCity ビルド構成) を使用して機能しました。要するに、これらは面倒です：

  • 適切なバージョン管理
  • 適切なパッケージ ソースを選択するためのリマインダー(技術的には CI パッケージはプレリリースとしてバージョン管理されますが、CI パッケージはプレリリースおよびリリースとは別にしてください)
  • CI pkg からプレリリースへのアップグレードは、 プレリリース タグが「CI」より上位の文字列でソートされている場合 (「Alpha」など)、問題になる可能性があります。この場合、uninstall-package "CI" の後に install-package "Alpha" が続きます。

お役に立てれば！

于 2012-09-14T04:56:43.387 に答える