1

私は自分のリリースストレージサーバーを作成することを考えています。これを行う前に、作成する代わりに統合を確認するために人々が何を使用するかを知りたいと思います。

では、内部アクセス用にビルドを保存するために何を使用しますか？

アーティファクトをアップロードしてから、さまざまなタグで参照できるWebアプリを探しています。これにより、アーティファクトをコンポーネントごとにグループ化したり、車両をリリースしたりできます。また、準備や昇進によるビルドごとのアクセス制御も必要です。

ステージングとは、ユーザーのコミュニティがアクセスできるように、ビルドされたアーティファクトをサーバーに配置することと定義します。アーティファクトは通常、アプリケーションまたはライブラリとドキュメントのいずれかを含むzipファイルです。ユーザーコミュニティは、開発者、QA、およびサービスの提供/運用です。基本的に、作成者、チェッカー、外部ユーザー。

アーティファクトを個別にリリースし、リリースビークルでグループとしてリリースします（たとえば、リリース1.1にはfoo 1.0.1とbar1.0.7が含まれています）。アーティファクトによっては、アクセスを制限したい場合があります。オペレーションはプレリリースされたビルドにアクセスできないようにする必要があり、限定された可用性リリースをダウンロードしたユーザーを追跡したい場合があります。

ですから、私が持っていないものを追加できるように、優れた拡張可能なデザインで私が望むことのほとんどを実行するツールを見つけたいと思っています。

ビルド後にビルドを管理するための優れたツールを知っている人はいますか？

例は次のとおりです。

  • クイックビルド/ラントビルド
  • チームフォージ
  • フォージを構築する
  • JiraとConfluenceのセット
  • ソナタイプネクサス
  • 自家栽培
  • 分岐を使用してdev->Qa->GAからのビルドを促進するSVNリポジトリ
4

2 に答える 2

0

ピーター、

多くの回答が得られていないので、私が働いている開発者であるUrbancodeのAnthillProについてお知らせします。

免責事項はありませんが、AnthillProは、開発者、チェッカー、運用など、話し合っている幅広い対象者に正確にサービスを提供するように設計されています。リストしたツールと比較すると、AnthillProは、BuildForge（当社の主要な競合製品）または緊密に統合されたアーティファクトリポジトリ（nexusなど）を使用したクイックビルドのようなものです。したがって、ビルドが実行され、ビルドの結果（およびビルドアーティファクト）を素敵なWebUIで表示できます。正しい権限を持つユーザーは、展開などの2次プロセスを実行したり、以前のビルドに対してテストしたりできます。また、選択したビルドの成果物も実行できます。

目標は、ビルドから、さまざまなテストツールや展開環境、リリースから本番までのビルドライフサイクル全体を管理することです。これは大きな厄介なスイートではありません。代わりに、SubversionやJiraなどのツールと統合して、すべてのリリースにソースと問題のチケット変更のマニフェストがあることを確認します。

リリースパッケージは、AnthillProの組み込みの依存関係システムにうまく対応します。お客様は、ソースコードをほとんどまたはまったく使用せずに、コンポーネントをリリースバンドルに関連付けるかパッケージ化する仮想プロジェクトを作成することがよくあります。

AnthillProが不十分な場合は、一般的に、プレリリースビルドを操作で確認できるようにします。ただし、「プレリリース」としてマークされていないビルドの操作によって、リリースの試行を即座に失敗/ブロックするルールを追加できます。AnthillProのステータスシステムにより、チームは「InQA」や「ApprovedforRelease」などのカスタムマーカーでビルドにフラグを立てることができます。ワークフローの実行に関するルールと組み合わせると、必要な制御が可能になります。一部のプロジェクトが特に機密性の高いものである場合は、役割ベースのセキュリティを使用してそれらをロックします。

それがあなたに調査する何かを与えることを願っています。

-エリック

于 2009-06-16T13:27:02.153 に答える
0

私のオプションは

AntHill、QuickBuild、TeamForge、BuildForge などの自動化システムを構築する

  • ファイルサーバー
  • ソース管理サーバー
  • Maven リポジトリ マネージャー (nexus、archiva)

私の目標は

  • 複数の基準 (アーティファクト タイプ、リリース車両、ステージ/フェーズ) によるグループ ビルド
  • 開発からビルドを促進 -> qa -> リリース済み
  • 開発ビルド、QA 対応ビルド、本番対応ビルドのアクセス制御を提供する

ファイル サーバーとしてのソース管理 (svn を使用)、または nexus を使用したファイル サーバーとしての maven リポジトリ マネージャーのいずれかに焦点を当てます。理屈は次のとおりです。

  • 労力を最小限に抑える
  • コストを最小限に抑える
  • 必要に応じて簡単に拡張できるものを使用します (要件が変わると確信しているため)。
  • Maven の使用は増加しており、最終的にはここでの主要なビルド テクノロジになるでしょう。

情報のおかげで。

于 2009-06-17T20:59:24.727 に答える