あなたの職場環境は Harvest SCM を使用していますか? 私はこれを2つの異なる場所で使用しましたが、ぞっとするようなものです. ある状況では、CVS をローカルで使用できるように変換スクリプトを作成し、睡眠中に Harvest システムに変更を毎日インポートしました。プログラマーの 80% が別の何かを求めているにもかかわらず、同社は Harvest の使用に熱狂的でした。それは不必要に複雑で、遅く、重かった。私が働いている場所で Harvest が使用されていないことは、今では私の仕事の要件です。
以前にハーベストを使用したことがある人はいますか? あなたの経験は何ですか？私と同じくらい悪いですか？他の別の回避策を採用しましたか? この製品が現在も購入されているのはなぜですか?
私は銀行でHarvestを使用するという利点があり、1つの簡単な変更を行うために15のステップを必要とする、スカムと極悪な、後方のトリプルフォークの文書化されていないチェックインガントレットのより惨めなハイブを見つけることは決してありません。彼らが分岐さえ使用していなかったことを気にしないでください。これは邪悪なツールであり、あなたをその手に負えさせないでください。
あなたの会社は CA と何らかの契約を結んでいる可能性があります。社内で他の多くの CA ソフトウェアを使用していますか?
編集：そうだと思います！
ここで遅く、ハーベストが大きなトピックであるため、いくつかのエピソードでこれに答えるつもりです。
まず、CA Harvest (製品のバージョン 7 と呼ばれるもの、バージョン 5 は CCC で、拡張は思い出せません。バージョン 12 は CA SCM と呼ばれます) は、単なる SCM ツールではありません。同様に、ClearCase はSCM ツール以上のものです。SVN、CVS、git、hg はすべて基本標準の SCM であり、それ以上のものではありません。
Harvest で得られるのは、SCM + ポリシーです。これにより、コードを保存およびバージョン管理し、そのコードが開発から本番まで組織全体でどのように成熟するかというポリシーにすべてをラップする場所が提供されます。QA にリリースする前にリード開発者がコードを承認する必要があるというポリシーを組織内に持っていますか? Harvest を使用すると、サインオフをポリシーとして定義し、それを適用できます。コードを「Dev」状態から「QA」状態に移行することはできません。リード開発者として指定されたプロジェクト内の 1 人がまさにそれを実行するまでです。SQL コードは処理を進める前に DBA によるサインオフが必要であるというポリシーがありますか? Harvest を使用すると、そのポリシーを定義して適用できるため、コードを移行する前にリード開発と DBA の両方の承認が必要になる場合があります。
Harvest は、ほとんどのソフトウェア組織にとって決してツールではありません。通常、金融業界や、非常に強力な規制フレームワークが実行できることを管理するビジネスで使用されます。銀行は、非常に厳しい監査要件を持つ Sarbannes-Oxley に準拠する必要があります。Harvest は、銀行資産への変更がライフサイクルを通じてどのように移動するかについて、あらゆる種類の制御とプロセスを定義する機能を提供します。毎日何百万人もの人々の安全と時間厳守に責任を負っている大規模な公共交通機関を知っていますが、Harvest のようなツールが提供する厳密に定義された制御メカニズムを必要としています。また、何千人もの開発者が毎日使用する環境で Harvest が使用されているのを見てきました。はい、誇張ではありません。文字通り 1 つの組織で 1000 人の開発者が世界中の小売業者のためにコードを書いています。
Harvest は完璧ではありません。バージョン 12 の方がはるかに優れていると思います。「それはばかげている」瞬間が多すぎます。CVS のようにファイルごとのバージョン管理を行い、CVS のような分岐とディレクトリのバージョン管理 (またはその欠如) を行い、私たちが知って恐れているすべての楽しみを備えています。ただし、それを知って受け入れると、私が使用した他のどの SCM よりも本質的に遅くはありません。コードをバージョン管理するだけでなく、もっと大きな仕事があります。
バージョン 12 でのもう 1 つの大きな利点は、他の CA ツールとの統合 (および非 CA ツールとの統合機能ですが、現時点ではそれほど多くはありません) です。Quality Center による欠陥追跡、Unicentre Service Desk によるトラブル チケット。 、SDM を使用したデスクトップへのソフトウェアの展開。これらのアプリ間の橋渡しを定義することで、これらの懸念事項がより緊密に統合され、通常は正確性と適時性にプラスの効果がもたらされます。
何千ものデスクトップとサーバー、メインフェーム/ミッドレンジ/ミドルウェア システム、鉄壁の変更管理プロセス、複雑さ、規制、契約、監査人など、膨大な複雑さを抱える世界規模の企業にソフトウェアを提供する場合、Harvest は必要なツール スイート全体の 1 つのツールにすぎません。数百人の顧客をサポートする 10 人の開発者のチームに単純な SCM が必要なだけの場合は、最適な方法ではありません。
次回は、Harvest が実際にどのように機能するか (リポジトリ、プロジェクト、ビュー、パッケージ、フォーム、プロセスなど) について追加しようと思います。これは、なぜ一部の組織が Harvest を使用するのか、なぜすべての人には使用できないのかを説明するのに役立つかもしれません。
数年前、銀行業界での短いギグで Harvest を使用しました。ほぼ使えなかったのは同意ですが、QAの担当者は気に入ってくれたようです。
私は2つの選択肢がある会社で働いていました。ClearCase または Harvest。Subversion はこれまで検討されたことがありませんでした。その理由は、ClearCase (IBM) と Harvest (CA) の両方がすでにメインフレームの長期契約を結んでいたからです。
Harvest を約 10 年間 (2000 年から 2010 年) 使用しており、現在は交換を検討していますが、非常に役に立っていると思います。Harvest (正式名称ではなくなりましたが、その名前をそのまま使用します) は、R&D で私たちをサポートするために実装した最初の主要なツールであり、当時はアプリケーション ライフサイクルの多くの側面 (コードのバージョン管理、分岐、自動テスト、回帰テスト、品質保証、多数のランタイム環境と本番環境への展開、ロールバック、緊急修正、メンテナンス更新など); 今日、私たちはより多くのことを知っており、開発プロセスは非常に役に立ちます (多くの改善の余地がないわけではありません)。私たちには非常に階層的な組織はありません (変更を承認する必要がある多くの検査官はいません)。
ユーザビリティに関する Harvest の (私たちにとっての) 欠点は、「x 行のコードを変更するためにプログラマーが何をする必要があるか」ということでした。今日（世の中には）ソースコードファイルへの書き込みアクセスを取得し、更新を行ってからファイルを再度返したり、開発プロセスの別の側面（テスト、展開など）に移動したりするための、Harvest よりも簡単で効率的な方法がたくさんあります。 .)。もう 1 つの欠点は値札です。高いです。
Harvest のメリット: ワークフローをサポートしているため、単一のシステムでコードのバージョン管理、ワークフロー、およびプロセスの自動化を管理できます。可能であれば、多数のシステムよりも 1 つのシステムを維持および改善する方が簡単です。内部プロセスへの cmd ライン アクセスを提供する (プロセスで必要な場合に特別なソリューションをスクリプト化できるようにする) ことに加えて、Harvest はグラフィック インターフェイスによって簡単に構成することもできます。これには「パッケージ」の概念があり、コードの変更に大量のメタデータを添付し、他の変更とは独立して変更を処理することを容易にします (完全なコードの塊を含む変更セットではなく、ファイル レベルでのバージョン管理)。これは、独立した緊急事態やメンテナンスの変更を処理するのに役立ちます。
開発者が単なるプログラマーであり、ソフトウェア開発のコーディングの側面だけを考えている場合、Harvest に非常に不満を感じる可能性があると思います。開発者が開発者であり、ソフトウェア開発はコーディング以上のものであり、コーディングはソフトウェアのライフサイクルのまさに始まりにすぎないことを理解している場合、彼は Harvest で多くのメリットを享受できると私は信じています。
私は過去4年間HARVESTを使用していて、それが大好きです。コードの動きを制御するためのサポートの種類は本当に素晴らしいです。HARVESTを使用して、アプリケーションをWebsphereにデプロイします。また、プラグインをアプリケーションと一緒にWebサーバーにデプロイする際にもすばらしい作業を行います。大規模なエンタープライズ環境でコードを移動するためのプロセスを導入したい場合、他のツールがHARVESTに近づくことすらできないと思います。