スター チーム 2005 から TFS 2010 with HISTORY に移行したいと考えています。費用対効果の高いツールや方法はありますか。Timely Migration ツールについては知っていますが、高すぎます。
1 に答える
これを行うためのツールはありません。Timely Migration の料金を支払うか、自分で作成するかで行き詰まっています。StarTeam からの履歴の取得は非常に複雑です。この理由は、ビューが歴史的にどのように見えるかによるものです。ビューを特定の時点にロールバックできます。これだけでも非常にうまく機能しますが、API を使用してビューに変更が発生したすべての時点にロールバックすることは事実上不可能です。これは、1) すべてに監査レコードがあるわけではないため、監査を使用できない、2) 監査レコードが消去されている、3) ビューの履歴を「再生」して生成する特別な機能があるためです。リスナー イベント (MPX が必要) が必要ですが、これでは多くのイベントが失われます。4) アイテムが共有、構成、分岐などされた場合、これらはプロジェクト内で監査を生成しません。5) たとえ生成されたとしても、すべての変更を取得するには、違いを分析してすべての変更を取得するために、ビュー履歴を 1 秒まで繰り返し処理する必要があります。つまり、プロジェクトが 1 か月間アクティブで、2 つのビュー構成を分析してそれらを比較するたびに 5 秒かかる場合、実際のプロジェクトの移行には 5 か月かかり、その間はロックダウンされます。
したがって、これを行う次の方法は、比較する「ベースライン」を確立することです。プロジェクトにナイトリーまたは継続的なビルドがある場合、または QA 認定された特定のビルドがある場合でも、ビルド ラベルを使用することは良い出発点です。このようにして、これらのベースラインを差分/比較のポイントとして使用し、その方法で履歴を取り込むことができます。これは完全な履歴ほど詳細ではありませんが、定義上、移行する最も重要な違いを取得しています。
ただし、このようにしても、異なるブランチ/ビューにまたがるブランチ/マージ ポイント間のリンクは維持されないことに注意してください。これを行う唯一の方法は、StarTeam データベースに直接アクセスしてこの情報を取得することです。
StarTeam から Subversion に移行するための独自のツール スイートを作成するために、これらすべての手順を実行しました。それは楽しくて面白くて不完全でしたが、いくつかの約束がありましたが、最終的には完成しませんでした. その理由の一部は、そこから得た価値よりもはるかに多くの時間が必要だったからです。
完全な履歴を維持することのビジネス上の価値は何か? StarTeam 管理者としてプロジェクト チームとこれを何度も経験した後、90% 以上の確率で、より良いアプローチはカットオーバーであることがすぐに明らかになりました。新しいシステムで新しい作業を開始し、古いシステムで作業を凍結できる時間を作ります。通常、プロジェクト チームのダウン タイムはほとんどありません。新しいシステムで大まかなタイムラインを作成するために、製品リリースの履歴を引き継ぐことから始めることもできます。TFS、BeyondCompare、またはその他の既存の比較ツールを使用して、プロジェクトのソース コード、ドキュメントなどの各状態を再現し、必要に応じてファイルをチェックインまたは削除して、TFS プロジェクトと調整します。持ち込むビルドごとに TFS プロジェクトにラベルを付けます。すべての TFS ビルド、作業項目、ユーザー、ロールなどを並べて、すべての準備が整っていることを確認します。次に、カットオーバー時に、StarTeam から最新の開発スナップショットを取得し、TFS プロジェクトをもう一度更新します。Starteam ユーザーをプロジェクトからロックアウトし (チェックインのために)、TFS での作業を開始します。TFS プロジェクトには、最も重要なベースラインの大まかな履歴があり、さらに履歴が必要な場合に備えて、StarTeam リポジトリをユーザーに公開しておくことができます。Starteam ユーザーをプロジェクトからロックアウトし (チェックインのために)、TFS での作業を開始します。TFS プロジェクトには、最も重要なベースラインの大まかな履歴があり、さらに履歴が必要な場合に備えて、StarTeam リポジトリをユーザーに公開しておくことができます。Starteam ユーザーをプロジェクトからロックアウトし (チェックインのために)、TFS での作業を開始します。TFS プロジェクトには、最も重要なベースラインの大まかな履歴があり、さらに履歴が必要な場合に備えて、StarTeam リポジトリをユーザーに公開しておくことができます。
考慮すべきもう 1 つの点は、プロジェクトの永続的なアーカイブを作成する方法です。リポジトリが十分に小さい場合は実行可能ですが、プロジェクトが大きくなるほど時間がかかります。まず、データベース全体とボールトを別のインスタンスにコピーし、そのコピーを起動して実行します。次に、アーカイブしたいプロジェクトを除いて、他のすべてのプロジェクトを削除します。オンライン パージを実行し、必ず最後まで実行してください。サーバーの再起動とパージが数回必要になる場合があります。完了すると、リポジトリ全体には、プロジェクトに必要なファイルとデータベース レコードのみが含まれているはずです。この時点で、データベースとボールトをバックアップして無期限に保持できます。これにより、既存の StarTeam リポジトリのサイズが縮小されます。
3 年以上 StarTeam を使用していませんでしたが、楽しい旅でした。お役に立てば幸いです。