企業にソース管理を切り替えるよう説得する方法 [終了]
https://stackoverflow.com/questions/44588
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私の現在の職場は現在移行期にあり、新しい所有者が引き継ぎ、ようやく物事が標準化され、適切なガイドラインが施行されつつあります。
しかし、私たちはまだ VSS を使用しています。実際には、それが最初にセットアップされたものであること以外に、VSS を使用する理由はありません。私たちは Visual Studio やそれを特に必要とするツールを使用していません。
長期的には、Subversion のようなものに移行する方がはるかに良い解決策になることを彼らに説得するために私が提示できる絶対的に最善の議論は何でしょうか。
解決
VSS はデータベースの管理を完全にクライアントに依存しています。クライアントがネットワーク上での書き込みの途中で接続を切断すると、ファイルはサーバー上でゴミ箱に捨てられます。ヒントだけでなく、すべての歴史。良いバックアップがあることを願っています。私はそれを経験してきました。悪い知らせです。
VPN またはその他のリモート接続を介した VSS の使用はひどいものです。データの転送には SMB が使用されており、ヒントを取得するにはファイルとそのすべての差分を取得する必要があります。汚い。
VSS が 1GB のデータで動作し始めるのを見たことがあります。データベースエラーなどMS (FAQ または KB のどこか) は、実際には 2GB が安全な最大制限であると言っています。優れた管理ツールがない (クライアントが亡命施設を運営している) ため、これに関する警告は実際には得られません。
何でも サーバー プロセスを使用して、ある程度のレベルのトランザクションと整合性制御を提供することは、優れたソリューションです。
他のヒント
最も適切な議論は、彼らを破壊活動に切り替えてほしい理由でなければなりません。:)
VSS についてはまったく知識がありませんが、「壊れていないなら直すな」という言葉が頭に浮かびます。VSS が壊れており修正が必要であることをマネージャーに示す必要があります。それがどのようにコストを節約するかを経営陣に示すことができれば、さらに良いでしょう。
@アダム・デイビス:ああ、実はアダム、VSS はひどいソース管理システムです。履歴を破損し、データを失った長い歴史があります。マージが苦手で、複数の開発者をうまく処理できず、非常に遅いです。経歴も貧弱です。Microsoft はそれを実際にはサポートしていません。Microsoft が自社の内部開発にこれを使用したことはなく、現在はより最新のソリューション (VSTS) を支持して販売さえしていないことがわかります。つまり、VSS と他の種類のソース管理のどちらかを選択する必要がある場合は、代替手段を選択してください。
優れたソース管理がもたらす機能を簡単に説明すると、次のとおりです。
- 誰が、いつ、どのファイルに対して、何を、どのような順序で行ったかのログを簡単に確認できる機能
- すべての過去のバージョンの履歴を保持する
- 簡単に過去のバージョンに戻ってファイルの特定のバージョンを再現し、古いバージョンで報告されたバグをより簡単に再現します。
- プロセス中にデータが失われることを心配することなく、削除されたコードを取得したり、不要な変更を削除したりすることができます。
切り替えを証明する書類があればコストが削減されます。それができない場合は、複数色のグラフやチャートを使用します。もしかしたらパワーポイントでのプレゼンテーションかもしれません。
インターネットには、VSS の欠陥についてよく書かれた記事が散らばっています。VSS から離れるための証拠としてこれを収集します。VSS がサポートできない主要な要件 (リモート作業、他の OS でのサポート、ツールの統合) を見つけて、問題を解決するために使用します。次に、組織の要件に適したソース管理システムを見つける必要があります。そのシステムは本当に Subversion ですか?選択したシステムのデモンストレーションをセットアップし、これを使用してその価値を証明します。
私は前の雇用主でこの変更を実装しました (最初は CVS に、次に SVN に)。それは成功しましたが、エッジ周りに多くのビットを構築し、多くの (時には信頼性の低い) オープンソース プロジェクトに依存する必要がありました。必要なすべてのツール。今思えば、Perforce、Vault、さらには Team System などのプロフェッショナル ツールを評価することを検討すべきでした。これらを評価すれば、CVS/SVN が「無料」の価格に値するかどうかについて、適切な価値判断を下すことができたはずです。
分岐と分岐を処理できるようになることは始まりです。
vss と並行して Subversion をしばらく使用してみると、おそらく上司を説得するための多くの議論が見つかるでしょう。そうでなければ、上司の言うことは正しいので、変える理由はありません。
Google で「vss 問題」や「ソース セーフの破損」について検索してもらうか、単純に Wiki ページを参照してください。そうすれば、ビジネスのこれほど重要な部分に賭けるのはおそらく長期的には実現不可能であると彼らに納得させるはずです。
あなたのチームの規模はどれくらいですか?(つまり、サラダを避けるかどうかではなく、メンバーの数を意味します) 6 人を超える非常にアクティブなユーザーが増え始めると、VSS は頭痛の種になります。
Microsoft がそれを使用しているとは真剣に疑っています (実際、カスタマイズされた Subversion または CVS の亜種を使用しているのではありませんか?)。自問する必要があります。会社が自社のドッグフードを食べないのであれば、なぜそれを食べるのでしょうか?
基本的な答えは、切り替えがビジネスのニーズを満たしていると主張する必要があるということです。例えば：
- 開発コストの削減
- 短いスケジュール (#1 の別の色合い)
- プロセス要件 (ソフトウェア要件のトレーサビリティやビルドの再現性など) を満たすのに適しています。
これらのことを主張するには、「これは問題があるのでコストを下げます」だけではなく、定量的なものも必要です。 右 やり方は！」。
注意すべき点の 1 つは、開発者は、最初に基本的なビジネス フィルターを通過せずに変更を行うことが有益であると自分自身を納得させるのがあまりにも簡単であるということです。そうなると、開発者はツールに不満を持ち、経営陣が言うことを聞いてくれないと考えて二重にイライラすることになります。上記の項目の 1 つでもチェックを入れることができない場合、経営陣を説得することはできません (経営陣が無能でない限り、それは別の質問になります)。
VSS ではなく Subversion を使用する理由
- フリーソフトウェア
- 管理が容易になる
- 「チェックイン」は、 原子!
- 分岐とマージが簡単
- 継続的な開発（すなわち、VSS は行き止まりです)
- 変更の追跡とログの表示のための優れたツール
- ツールセットやプラットフォームに依存しないが、多くのツールとも統合可能
私はマネージャーにその提案をしましたが、とても簡単に売り込むことができました。特に分岐に関しては、非常に使いやすいことがわかりました (私たちのプロジェクトでは、VSS での「共有と固定」に 5 時間かかり、その後、各操作が完了するまでにさらに時間がかかりました!)。
たとえ壊れていなくても、VSS からの移行には潜在的な利点があります。まず、最も簡単なことですが、新しい VSS ライセンスを購入する必要がありません。第 2 に、VSS 製品には欠陥の例が多数あります (MS によっても認められている欠陥もあります)。SVN の学習曲線は少なくとも VSS と同じくらい低く、開発者がソース管理システムに満足していれば、早い段階から頻繁に SVN を使用する可能性が高くなります。それはあなたの会社にとってリスクを大幅に減らすことにつながり、それは良い利点です。
@ジェイソン:VSSが壊れています。
VSS からの変更を促す最も強力な方法は、ソース コードがどれほど重要な資産であるかを指摘することだと思います。誠実にリスクを取ることは、ビジネス上の賢明な選択ではありません。
プログラマーがこの資産の作成者であり、プログラマーの生産性が向上するということは、ソース コード資産の価値が高まることを意味することを付け加えてください。Joel on Software は、プログラマーへの投資が会社にとっていかに大きな勝利であるかをよく話します。
ここにある他の回答はすべて、主張するときに指摘できる具体的な理由を説明しています。
他の回答で示されている技術的な点に加えて、次のような非技術的な理由に対応する準備が必要な理由が潜んでいる可能性があります。
あなたの会社がオープンソース ソフトウェアに対する (または誤った恐怖) ポリシーを持っているかどうかを調査する必要があります。会社やその弁護士が、どのライセンスがプロプライエタリ コードに「感染」し、どのライセンスがプロプライエタリ コードに「感染」しないのか、またプロプライエタリ コードに影響を与えないオープン ソース コードで何ができるのかを詳しく理解していないと、プロプライエタリなツールからオープンソース ツールに切り替えてもらうのに苦労しています。（そして、もっと大きな教育の仕事を抱えているかもしれません。）
プロプライエタリからの切り替えを主張する場合（例：VSS) をオープンソースに (例:Subversion) また、コードの品質と、コードに関する保証やその他の契約上の権利が不要であることを擁護する準備も必要です。
