問題タブ [alm]

いくつかのツールを使用して、Linux Ubuntu に ALM サーバーをインストールしています。

• ジェンキンス
• ネクサス
• メイヴン
• ソナー
• SVN
• 蟻

Nexus と Jenkins を同じ Tomcat サーバー (/Webapps) にデプロイしました。

UbuntuでVM仮想ボックスを使用しています（6 CPU、4GOのメモリ）

問題は、CPU の過負荷やメモリのオーバーフローなしにサーバーを実行するためのハードウェア要件は何ですか) です。

前もって感謝します。

ほとんどの大規模なエンタープライズ アプリケーション (Microsoft AX、NAV、SAP) では、通常、コードはさまざまなアプリ シナリオ間で移行されます: 開発、テスト、受け入れ、生産...

私たちは VisualStuido と TFS を使用して開発を行っており、これを達成するために、データベース (運用とテスト) を複製し、変更を手動で追跡し、TFS ログをチェックし、データベース バージョン間の差分スクリプトを手動で生成しています...

メインアプリケーションのライフサイクルを管理するのは難しいですか?プロジェクト/顧客ごとにカスタマイズして複数のマイクロ ALM を処理するのは大変な作業です!!

Migrator.NET のようなツールを見つけましたが、非常に手作業です。このシナリオを実装し、変更を自動的に追跡および移行するツールはありますか?

TFS ビルドを取得して Specflow テストを実行するにはどうすればよいですか? ローカル VS ビルドでテストを実行していますが、TFS ビルドでは取得されません。ビルドで specflow テストを実行するための手順を投稿して、結果を報告してください。ありがとう。

レガシーシステムに最新のコードバージョンシステムを使用する方法を調査しています。ただし、実際には解決方法がわからない問題がいくつかあります。これをどのように組織化すべきだと思いますか。

1. コードの一部は弊社が責任を負い、一部はお客様が責任を負います。

   私たちの開発システムにあるコードはマスターであり、すべての変更はそこで行われ、顧客に送信されます。ここまでは一般的なプロジェクトのようなものです。ただし、数百のファイルを含む一部のディレクトリでは、クライアントがコードを担当します。お客様は、必要に応じてこれらのファイルを変更でき、当社に通知する必要はありません。それらの更新を行う場合、これらのファイルのコピーを取得し、新しいバージョンを顧客に提供する前に変更をマージする必要があります。

2. システムが生きてきた 25 年間で、システムの 4 つの基本バージョンをリリースしました。ただし、当社の 6 人の顧客は異なるバージョンのシステムを使用しているため、検討する必要があります。また、お客様にはそれぞれ独自の要件があり、お客様ごとに大幅な調整を行っています。

3. 同じファイルに関連するいくつかの並行プロジェクトがあります。現在、さまざまなプロジェクトが互いに干渉するという大きな問題があるため、さまざまなブランチに変更を加えることで大きなメリットが得られます。しかし、これをどのように整理するのでしょうか? 1 人の顧客のみに影響するプロジェクトもあれば、複数の顧客が関与するプロジェクトもあります。また、一部のプロジェクトは、将来の新しい基本バージョンに導入される可能性があります。

私の質問は、これを新しいバージョン システムでどのように整理するかです。

1 つのプロジェクトで一緒に作業している約 20 人の開発者のチームがあります。このプロジェクトには、ハードウェア、ファームウェア、ソフトウェア、さらには Web 機能を含むいくつかのコンポーネントがあります。TFS 2013 を使用してプロジェクト全体の進捗状況を追跡したいと考えています。しかし、GIT リポジトリを使用してソース管理側を管理する方法を理解するのに苦労しています。ハードウェア チームは、回路やその他すべてのハードウェアをレイアウトするためのバイナリ ファイルを扱っているため、コードをロックして作業できるようにする必要があります。現在、GIT リポジトリを使用して、ハードウェア部分を独自のプロジェクトにし、ファームウェア/ソフトウェア側を独自のプロジェクトにすることを検討しています。

私たちが懸念しているのは、TFS 2013 では、作業項目を同じプロジェクトからのチェックインにのみ関連付ける必要があるように思われることです。これを克服するために、すべてのファームウェアとソフトウェアを同じプロジェクトに配置しますが、いくつかの異なる領域に分割します。すべてが同じプロジェクト内にあり、同じ GIT ソース コード リポジトリを使用している場合、異なるソフトウェア領域が異なる時期にリリースされ、各領域にいくつかのブランチがある場合に問題が発生する可能性があることを懸念しています。組み合わせると、大量のブランチになる可能性があります。これらの管理に問題はありますか？

作業項目が複数のプロジェクトにまたがるように TFS 2013 を構成できますか? すべてが同じ TFS プロジェクトにある場合でも、コードの別々の領域に別々のリポジトリを使用するように GIT を設定できますか?

これを管理する方法について何か提案はありますか、またはこれは TFS 2013 では管理できませんか?

ヘルプ、コメント、またはアドバイスをありがとう。

これを後で追加しました：

この投稿への回答を読み、私の仲間の何人かと話をした後、上記のシナリオで私たちがたどる最善の方法は、2 つのプロジェクトを持つことであると思われます。1 つはハードウェア用、もう 1 つはソフトウェア/ファームウェア用です。ハードウェアには独自の非 GIT リポジトリがあり、ソフトウェア/ファームウェアは単一の GIT リポジトリを共有します。GIT リポジトリに master ブランチを定義します。ソフトウェア プログラムごとに 1 つ。プログラムには、それぞれ異なるエリアが割り当てられます。このようにして、ソフトウェアとファームウェアについて、プログラムを分離したままにしておくことができ、プロジェクト管理とコラボレーションの目的で、TFS の同じプロジェクトでそれらすべてを表示することもできます。また、すべてのチェックインを TFS アイテムに関連付けることができるようになり、QA がバグをタスクやエリアに関連付けることができるようになります。