カウボーイプログラマーにソース管理を使用するよう説得するにはどうすればよいですか？

更新
私は4人の開発者の小さなチームで働いています。それらはすべてソース管理を使用しています。それらのほとんどはソース管理に耐えられず、代わりに使用しないことを選択します。ソース管理は専門能力開発の必要な部分だと強く信じています。いくつかの問題により、ソース管理を使用するように説得することが非常に困難になります。

• チームはTFSの使用に慣れていません。2回のトレーニングセッションを行いましたが、1時間しか割り当てられていませんでした。
• チームメンバーは、サーバー上のコードを直接変更します。これにより、コードが同期しなくなります。最新のコードで作業していることを確認するためだけに比較が必要です。そして、複雑なマージの問題が発生します
• 開発者が提供する時間の見積もりには、これらの問題の修正に必要な時間は含まれていません。ですから、nonoと言うと10倍時間がかかります...これらの問題を絶えず説明し、自分自身を危険にさらす必要があります。
• サーバー上の物理ファイルは、〜100ファイルにわたって未知の点で異なります。マージには、当面のプロジェクトの知識が必要であり、したがって、開発者の協力を得ることはできません。
• 他のプロジェクトは同期していません。開発者はソース管理に不信感を持ち続けているため、ソース管理を使用しないことで問題を悪化させています。
• 開発者は、マージはエラーが発生しやすく、難しいため、ソース管理の使用は無駄だと主張します。これは議論するのが難しいポイントです。なぜなら、ソース管理がひどく誤用され、ソース管理が継続的にバイパスされると、間違いが起こりやすいからです。したがって、彼らの見解では証拠は「それ自身のために語る」。
• 開発者は、サーバーコードを直接変更し、TFSをバイパスすると時間を節約できると主張します。これも議論するのが難しいです。開始するコードを同期するために必要なマージには時間がかかるためです。これに私たちが管理する10以上のプロジェクトを掛けます。
• 永続ファイルは、多くの場合、Webプロジェクトと同じディレクトリに保存されます。そのため、公開（完全公開）は、ソース管理にないこれらのファイルを消去します。これはまた、ソース管理に対する不信感を引き起こします。「公開するとプロジェクトが壊れる」ためです。これらの場所はweb.configで設定されておらず、多くの場合複数のコードポイントに存在するため、これを解決する（保存されたファイルをソリューションサブフォルダーから移動する）には多大な時間とデバッグが必要です。

だから、文化はそれ自体が持続します。悪い習慣はより悪い習慣を生みます。悪い解決策は、新しいハックを駆り立てて、より深く、より時間のかかる問題を「修正」します。サーバー、ハードドライブのスペースを手に入れるのは非常に困難です。それでも、ユーザーの期待は高まっています。

この状況で何ができますか？

これはトレーニングの問題ではなく、人的要因の問題です。彼らは望んでおらず、障害を作り出しています。彼らの異議の根本的な原因である壊れたグループのダイナミクスに対処する-通常は恐怖、それは単に変化を恐れるのか、それとももっと不吉なのか。

今日、または過去20年間、ソース管理に抵抗したプロの開発者はいません。かつて、約30〜40年前、コンピューターが遅く、ソース管理がさらに遅く、プログラムが1つの500行ファイルで構成されていたとき、それは苦痛であり、それを使用しない正当な理由がありました。これらの異議は、私が考えることができる最悪の種類のカウボーイからのみ来ることができます。

システムは彼らに彼らの生活を何らかの形で困難にしているのですか？それが何であるかを調べ、異議を無効にするようにシステムを変更してください。完了するまで繰り返します。

GITまたはMercurialをご覧になることをお勧めします。各ソースコードツリーにリポジトリを作成できます。彼らは気付かないこともあり、今のようにハッキングを続けることができます。彼らがコードベースにハッキングした変更を追跡したり、コミットしたり、他のソースツリーにマージしたりすることができます。あなたが1つのコマンドで彼らのねじ込みの1つをロールバックし、彼らのロバを救うとき、彼らはあなたに感謝さえするかもしれません（それを期待しないでください）。最悪の場合、あなたはボスの前で見栄えが良く、ボーナスとして、彼らを彼らがカウボーイのように見せるようにします。

マージには、プロジェクトの素晴らしい知識だけでなく、

その場合、私はあなたがパドルなしでことわざの小川まで上がっているのではないかと心配しています。マージがオプションではない場合、どちらも実装されていないため、あるブランチにすでにある機能（緩やかに使用される用語）を別のブランチに追加することはできません。

もし私があなただったら、私のキャリアの見通しを再考するでしょう...

時々、現実世界の問題により、使用することが非現実的になります。

偽。

チームがソース管理の使用に慣れていない場合、トレーニングの問題が発生する可能性があります

これは、ソースコード管理とトレーニングとは関係ありません。トレーニングは簡単、安価、効率的で、数時間で完了します。ソースコード管理を使用しないと、コストがかかり、リスクが高く、非効率的であり、問​​題は永遠に続きます。

チームメンバーがサーバー上のコードを直接変更すると、さまざまな問題が発生する可能性があります。

それがトレーニングの問題です。再び。ソースコード管理とトレーニングとは関係ありません。

開発者は引き続きソース管理に不信を抱いているため、ソース管理を使用しないことで問題を悪化させています

彼らは、ソースコード管理を使用する方法について訓練される必要があります。コストを削減し、リスクを軽減し、物事を簡素化し、より効率的です。毎回配当を支払う1回限りの投資です。

この種の状況で何ができるのでしょうか？

ソースコード管理の使用方法に関する全員のトレーニングを開始します。

更新

開発者は、ソース管理を直接変更すると時間を節約できると主張します。

それらが間違っているので、これがどれほど間違っているかを正確に示すためにデータを収集することが重要です。

しかし残念なことに、経営陣は、長期的には費用のかかる即時対応に報いるようです。

この報酬システムを克服する唯一の方法は

A）長期的なコストが見かけ上の短期的な値よりも高いことを確認します。

B）短期的な破損（直接的な変更）が長期的な正しいソースコード管理よりも価値があると思わせる実際に存在する実際の報酬を特定します。誰が間違ったことをしていると頭をでられますか？彼らは頭をどのように叩きますか？誰があげますか？物事を修正するために、あなたは間違っているものと実際に人々を奨励している特定のマネージャーに名前を付ける必要があります。

C）短期的な迅速な対応ではなく、長期的な価値を重視する改訂された報酬システムを推奨します。さまざまな理由で頭にさまざまなパット。

D）長期的な価値のために見つけた報酬で人々を訓練する。短期的な迅速な応答よりも明らかに大きい値。

ソース/バージョン管理の使用を拒否する開発者は、そのように単純に解雇されるべきです。既に指摘したように、それを使用しないことの固有のリスクとコストは、それが被るオーバーヘッドよりもはるかに大きいです。これに異議を唱えようとする人は、単にソフトウェア開発に関与するべきではなく、私はそのような人々と働くことを拒否します。

最初に問題を解決し、継続的な統合サーバーを設定してソース管理をdevに組み込みました。次に、フォルダーアクセスを読み取り専用にロックダウンし、ソース管理を回避してファイルを直接変更するのを防ぎます。

ローカルでバグを再現できない日はPITAですが、それ以外は、CIサーバーによって自動的にdevにプッシュされることを知っているので、作業、チェックイン、続行ができる方が優れています。

あなたの痛みが聞こえます。いくつかの職場に足を運んで、「ソース管理」がネットワークドライブ上の共有フォルダーであることを見つけました。問題は一般的に、彼らのアプローチが他のものよりも優れていると信じているからではなく、単に機能し、ソース管理をうまく統合するワークフローに導入されたことがない。

フラットアースチーム構造では、変更をトップダウンでプッシュすることは、状況にアプローチする最善の方法ではないかもしれないと説明しました。試してみる価値のある方法の1つは、他の開発者の1人または2人から直接買収して、コンセプトが勢いを集めることです。他の開発者が1人でも参加すると、チームの残りのメンバーにそれを広めるのがはるかに簡単になります。彼らにコンセプトをゆっくりと紹介し、小さなサイドプロジェクトに取り組み始めて、それをGitで立ち上げて、あるいはGitHubでホストされている何かを分岐させます。

シンプルに始めて、日々のワークフローとは別に概念をゆっくりと紹介します。人間は、物事を学び、変化に適応するのが得意です。特に、その変化が直接的な利益をもたらす場合（進化を考えてください）。ただし、一度に小さな変更の全体を提示すると、疎外されます。ソース管理がどのように機能し、それが提供する利点を把握したら、内部プロジェクトの1つに統合してみてください（新しいプロジェクトを開始する場合は、導入するのは大変な時期です）。必要に応じて、他のプロジェクトを既存の方法で機能させます。これは、適切なコード制御の利点を強調するのに特に効果的です。

それが失敗した場合、実行します。

明らかに、自分の状況を特定して修正するための技術的なスキルを持っています。あなたの問題は人間とプロセスに関連しています。

人々はビジョンよりも例に対してはるかによく反応する傾向があるため、自分でそれを「修正」することをお勧めします。

最新のソースのコピーを取得し、バージョン管理しやすいように再構築し、便利で前向きな構造で新しいプロジェクトを作成します（ブランチの処理方法、サードパーティの依存関係を置く場所などを考えます）。あなたはおそらく自分の時間にそれをしなければならないでしょう。

次に、同僚と経営陣を部屋にドラッグして、21世紀のソフトウェア開発の様子を見せます。現在のシステムで障害を説明し、新しい構造でそれらがどのように除去されるかを示します。

また、ソースのキーパーとして自分を設定する必要があります-気にするのはあなただけであるように見えるので、（技術的または心理的手段を問わず）人々に固執させることはあなた次第です計画。顧客に送られるのは、ソース管理外のビルドマシンからだけであることを確認してください。規則を破って大混乱を引き起こす人々を儀式的に辱めます。ドーナツを使って賄beを贈りましょう...

そのすべてがあまりにも多くの努力のように思える場合（他のすべての答えで言われているように）-別の仕事を得る。彼らはあなたの時間の価値がありません。

ステップ1-無能なマネージャーを解雇せよ！

手順1を実行できない場合は、ソース管理から取得したスクリプトのみにprodに展開を制限するようにマネージャーを取得してください。開発者（prodの生産権を持っていてはいけない場合は、手順1を参照してください）がデプロイしたいものをソース管理から取得する必要があります。これにより、C＃コードだけでなくデータベースに使用するように最初に切り替えたときに、ソースコントロールを使用しないという問題が解決しました。

異なるバージョンのファイルと、その違いを確認する機能を望まない人はいますか？分岐や複雑なものは忘れてください。彼らも基本を取得していません。テスト環境で最も基本的な変更を行うことなく、実稼働ファイルを直接変更することは非常識です。私は何人かの個人と仕事をしたことがありますが、ありがたいことに同じプロジェクトに取り組んだことはありません。

あなたの同僚は怠け者にはバカすぎます。それは時間の無駄です。あなたが望むのは、マネージャーを訓練することだけです。管理者は、すべての形式の管理が好きなので、ソース管理が好きです。それらを重要に感じさせます。他をねじ込みます。あなたは彼を置き換えることができないので、リーダーを修正することはあなたの唯一の希望です。他の有能な開発者とのネットワークを開始し、オープニングがあるときに彼らをチームに参加させるか、彼らを彼らの店で雇ってもらう。

これは、悪い慣行が広範に使用されているため、修正することが事実上不可能になるプロジェクトの良い例です。修正するにはフリーズが必要なので、すべてを中断することなくクリーンアップできます。残念ながら、そのようなプロジェクトは通常（明らかな理由により）バグが多すぎて数か月間凍結できないため、重大なバグは1日おきに修正する必要があります。

ダーティバージョンはこれらの毎日のバグ修正で処理されている間、プロジェクトをフォークしてクリーンバージョンを作成したくなるかもしれません。しかし、最も可能性の高い結果は、「クリーン」バージョンが終了した数か月後、どのバグ修正と変更がフォーク以降に組み込まれたかを誰も伝えることができないということです。行った変更に関する記録を保持します）。クリーンバージョンは古く、ダーティバージョンはまだ動作しますが、どうなりますか？クリーンバージョンがダンプされ、否定的な意見が正しいことが証明されました。

明らかな「新しい仕事を探す」以外に、答えは上記のすべてです。

最初に管理に移動して、ソース管理への移行と使用の強制を行います。その後、サーバー上で直接作業することを意味する場合でも、物事を実行し続けるために必要なことを行います。ソース管理ですべてを取得するプロセスを開始します。

別のオプションは、最新版がサーバー上にあることを確認し（それは関係なく行う必要があります）、最新版から新しいリポジトリを完全に開始することです。あなたは歴史を失いますが、この時点でそれは小さなジャガイモです。

あなたの説明から、状況に1つ以上の問題があると思われます-開発チームが制御不能であるか、悪いソース管理ソリューションが実装されています。いずれにせよ、ソース管理ソリューションを使用することは開発チームの責務です。プロダクションサービスでソースコードを直接変更することは、問題の発生をただ懇願するだけです。

私の経験から、すぐに実行する必要がある最初のステップは、ソース管理を運用サーバーと同期することです。このステップは、実動コードのコピーを取得してチェックインするだけの簡単なものです。prodコードは、おそらくチームが開発しているベースです。このステップは、既存のソース管理システムに漂っているコードとのマージによって拡張する必要があるかもしれません。コードはdevからintegration / QA（またはその両方）に流れてから、stageまたはstage / productionに流れます。

次に、管理はソース管理の使用を義務付ける必要があります。簡単に言えば、ビルドがソース管理システムからのものではない場合、コードを実稼働環境にデプロイすべきではありません。本番アクセスはサポートチームのみに制限する必要があり、本番の問題をトラブルシューティングするためにdevに制限付きアクセスが与えられます。開発者は通常、本番環境へのコードのホットデプロイを絶対に行わないでください。特に開発者がプレッシャーにさらされている場合、本番環境の問題が必ず発生する可能性があります。

経営陣は間違いなくここでの問題をよりよく処理する必要があります。コードがprodに直接適用される（そしてソース管理に入らない）場合、開発を維持することはほとんど不可能です。

本当の問題は、カウボーイコーダーがバージョン管理を使用しないことではありません。本当の問題は、彼らが既に何かをする方法を選択していて、あなたが彼らのプロセスを変えようとしているということです。選択したプロセスにはバージョン管理が含まれていません。プログラマー自身が問題に気づかない限り、すべてのプロセス変更は困難です。既存のシステムが十分であるという感覚がある場合、いくつかの異なるシステムを課そうとすることは無益です。私たちはボーグです、あなたは同化されます。もちろん、彼らはボーグになるために戦っています。

あなた自身の健全性のために、変更を追跡できるように、Gitまたは別のDVCSを自分のマシンにセットアップすることをお勧めします。同僚の変更をリポジトリに頻繁にインポートします。可能な限り競合を解決します。これにより、同僚の精神異常から部分的に保護されます。

あなたは、開発者がソース管理を使用すべきだと経営陣が言ったことに言及しました。悪になりたければ、TFSへの変更をチェックし、リポジトリを定期的に公開することでこれを実施できます。したがって、TFSにない変更はすべて上書きされます。（独自のDVCSも維持している場合は、2つの同期を維持する必要があります。）そのための正当な理由は、管理者からの指示に従うことです。同僚が変更を上書きすることにうんざりしている場合は、TFSを使用するように招待します。そして、チェックインされていない変更を壊し続けます。同僚が寛容になるか、解雇されるまで続けます。

開発以外のサーバーをロックダウンします。構成マネージャーを使用します。定期的に識別可能なビルドを実行します（タグに対して）。すべての変更セットにタグを付けます（つまり、バグごとに1つの変更セット）。また、各ビルドにタグを付けます。開発とプロダクションの間にQAタイプシステムが必要です（少なくとも）。正しいビルドタグを使用してQAシステムにビルドします。「ビルドを破る」ために悲しみを与えます。

問題（本番環境でのみ表示される）を再作成/修正できない状況に陥ったことはありません。はい、私は開発システムで問題を再現するために何時間も費やしました（さらに、問題がわかったら回帰テストに追加できます）。

私たちは、これらすべての悪いことをした多くのカウボーイ請負業者とプロジェクトをやりました。その後4週間かけて掃除を行い、上記のプラクティスを実施します。それ以来、プロジェクトにはこれらの問題は一切ありません。

見積もり：

チームはTFSの使用に慣れていない

TFSは、Microsoft Team Foundation Serverであることが判明しました。

私の最初の本能は言う：「これはMicrosoft Visual SourceSafeの最新リリースです」

私はあなたの同僚の側にいて、本当に反対します。