カウボーイプログラマーにソース管理の使用を説得するにはどうすればよいですか？
[〜＃〜]更新[〜＃〜]
私は4人の開発者の小さなチームで働いています。彼らはすべてソース管理を使用しています。それらのほとんどはソース管理に耐えることができず、代わりにそれを使用しないことを選択します。私は、ソース管理が専門能力開発の必要な部分であると強く信じています。いくつかの問題により、ソース管理を使用するように説得することが非常に困難になっています。
- チームは [〜＃〜] tfs [〜＃〜] の使用に慣れていません。私は2回のトレーニングセッションを行いましたが、1時間しか割り当てられず、不十分です。
- チームメンバーはサーバー上のコードを直接変更します。これにより、コードが同期しなくなります。最新のコードで作業していることを確認するためだけに比較が必要です。そして、複雑なマージの問題が発生します
- 開発者が提供する時間の見積もりには、これらの問題の修正に必要な時間は含まれていません。したがって、nonoと言うと、10倍長くかかります...これらの問題を常に説明し、自分自身を危険にさらす必要があります。経営陣が私を「遅い」と認識している可能性があるためです。
- サーバー上の物理ファイルは、未知の点で100ファイルを超えて異なります。マージには、手元にあるプロジェクトの知識が必要です。そのため、開発者の協力を得ることはできません。
- 他のプロジェクトは同期していません。開発者は引き続きソース管理に不信感を抱いているため、ソース管理を使用しないことで問題がさらに悪化します。
- マージはエラーが発生しやすく困難であるため、ソース管理の使用は無駄であると開発者は主張します。これは論議するのが難しい点です。ソース管理がひどく誤用され、ソース管理が継続的にバイパスされているとき、それは確かにエラーを起こしやすいからです。したがって、証拠は彼らの見解では「それ自体のために語っています」。
- 開発者は、TFSをバイパスしてサーバーコードを直接変更すると時間を節約できると主張します。これも議論するのは難しいです。コードを同期するために必要なマージで始まるには時間がかかるためです。これに、管理している10以上のプロジェクトを掛けます。
- 永続的なファイルは、多くの場合、Webプロジェクトと同じディレクトリに保存されます。したがって、公開（完全公開）すると、ソース管理にないこれらのファイルが消去されます。これは、ソース管理に対する不信感も引き起こします。 「出版はプロジェクトを壊す」からです。これらの場所はweb.configで設定されておらず、多くの場合複数のコードポイントに存在するため、これを修正する（格納されたファイルをソリューションサブフォルダーから移動する）には、かなりの時間とデバッグが必要です。
ですから、文化は存続します。悪い習慣は悪い習慣を生みます。悪い解決策は、新しいハックを引き起こして、はるかに深く、時間のかかる問題を「修正」します。サーバー、ハードドライブのスペースを手に入れるのは非常に困難です。しかし、ユーザーの期待は高まっています。
この状況で何ができますか？
それはトレーニングの問題ではなく、人的要因の問題です。彼らは望んでおらず、ロードブロッキングを作成しています。壊れたグループのダイナミクスに対処します。彼らの反対の根本的な原因は何ですか-通常は恐れます、それは単に変化を恐れるか、それとももっと不吉なことですか。
今日、または過去20年間、ソース管理に抵抗したプロの開発者はいません。 30年か40年ほど前、コンピュータが遅くなり、ソース管理がさらに遅くなり、プログラムが500行のファイルで構成されていたとき、それは苦痛であり、それを使用しない正当な理由がありました。これらの異論は、私が考えることができる最悪の種類のカウボーイからのみ発生する可能性があります。
彼らにシステムが強制され、何らかの形で生活を困難にしていますか？それが何であるかを調べ、異議を無効にするようにシステムを変更してください。完了するまで繰り返します。
GITまたはMercurialを確認することをお勧めします。各ソースコードツリーにリポジトリを作成できます。リポジトリに気付かれることもなく、ハッキングを続けることができます。あなたは彼らがコードベースにハッキングした変更を追跡し、コミットを行い、他のソースツリーにそれらをマージすることができます。彼らがあなたに数週間の努力を数秒で別の製品にマージするのを見ると、彼らは彼らの考えを変えるかもしれません。 1つのコマンドでそれらのねじ上げの1つをロールバックし、それらのお尻を保存すると、彼らはあなたに感謝するかもしれません（それを当てにしないでください）。最悪の場合、あなたはボスの前で見栄えが良く、ボーナスとして、彼らを彼らがいるカウボーイのように見せます。
マージにはプロジェクトの優れた知識だけでなく
その場合、私はあなたがパドルのないことわざの小川を上がっていると思います。マージがオプションではない場合も、それを実装する場合もないため、1つのブランチ（大まかに使用されている用語）に既にある機能を別のブランチに追加することはできないと言っています。
もし私があなただったら、私のキャリアの見通しを考え直します...
時々、現実世界の問題は使用することを非現実的にします。
いいえ。
チームがソース管理の使用に慣れていない場合、トレーニングの問題が発生する可能性があります
これは、ソースコード管理とは関係がなく、トレーニングとはすべて関係があります。トレーニングは簡単、安価、効率的で、ほんの数時間で完了します。ソースコード管理の使用に失敗すると、コストがかかり、リスクが高く、非効率的で、問題が解決しませんforever。
チームメンバーがサーバー上のコードを直接変更すると、さまざまな問題が発生する可能性があります。
それがトレーニングの問題です。再び。ソースコード管理とは関係なく、トレーニングとはすべて関係あります。
開発者はソース管理に不信感を抱き続けているため、ソース管理を使用しないことで問題を悪化させています
彼らは、ソースコード管理を使用する方法について訓練を受ける必要があります。それはコストを削減し、リスクを減らし、物事を簡素化し、より効率的です。毎回配当を支払うのは1回限りの投資です。
このような状況で何ができるでしょうか？
ソースコード管理の使用方法について全員にトレーニングを開始します。
更新
開発者は、ソース管理を直接変更すると時間を節約できると主張しています。
それらが間違っているので、これがどれほど間違っているかを正確に示すためにデータを収集することが重要です。
しかし悲しいことに、経営陣は長期的に見てコストがかかる即時対応に報いるようです。
この報酬システムを克服する唯一の方法は、
A）長期的なコストが、見かけの短期的な値より高いであることを特定します。
B）短期的な破損（つまり、直接的な変更）が長期にわたる正しいソースコード管理よりも価値があるように見える、実際に実施されている実際の報酬を特定します。誰が間違ったことをしたことで頭が痛くなるのですか？彼らはどんな頭をなでますか？誰がそれを与えるのですか？物事を修正するために、あなたは間違っているものと、実際に人々を励ましている特定のマネージャーを挙げなければなりません。
C）短期の迅速な対応ではなく長期的な価値を重視する改訂された報酬システムを推奨します。さまざまな理由で頭を軽くたたく。
D）長期的な価値のために見つけた報酬について人々を訓練する。短期の高速応答よりも明らかに大きい値。
ソース/バージョン管理の使用を拒否する開発者は、そのように簡単に解雇されるべきです。あなたがすでに指摘したように、それを使用しないことの固有のリスクとコストは、それが何桁ものオーバーヘッドを被るオーバーヘッドを上回ります。これに対して反論しようとする人は、ソフトウェア開発に関与すべきではないので、そのような人との共同作業を断るつもりです。
まず、継続的インテグレーションサーバーをセットアップしてソース管理をdevに構築することで問題を解決しました。第2に、フォルダアクセスを読み取り専用にロックして、人々がソース管理を回避し、ファイルを直接変更するのを防ぎます。
ローカルでバグを再現できない日にはPITAですが、それ以外は、CIサーバーによって自動的に開発にプッシュされることがわかっているので、作業、チェックイン、移動を行うことができます。
あなたの痛みを聞きます。私はいくつかの職場に足を運び、「ソースコントロール」がネットワークドライブ上の共有フォルダであることを確認しました。一般的に問題は、そのアプローチが他の方法よりも優れていると信じているからではなく、単に機能するだけで、ソース管理を正常に統合するワークフローに導入されたことはありません。
フラットアースチームの構造では、変更を上から下にプッシュすることは状況に対処するための最良の方法ではない可能性があることを説明しました。試してみる価値のある方法の1つは、1つまたは2つの他の開発者から直接バイインして、コンセプトが勢いを増すようにすることです。他の開発者が1人でもいると、それをチームの残りのメンバーに広めるのがはるかに簡単になります。ゆっくりとコンセプトを紹介します。たとえば、小さなサイドプロジェクトで作業を開始し、それを開始して Git に入るか、または GitHub でホストされているものにブランチします。
シンプルに始め、日常のワークフローとは別に、ゆっくりと概念を紹介します。人間は物事を学び、変化に適応するのが得意です。特に、その変化が彼らに直接的な利益をもたらす場合（進化を考える）。しかし、小さな変更の束全体を一度に提示すると、それは疎外になります。ソース管理のしくみとそれが提供する利点を把握したら、内部プロジェクトの1つにそれを統合してみてください（新しいプロジェクトを開始する場合は、導入するのがとても悪い時期です）。他のプロジェクトも同様に既存の方法で機能させてください。これは、まともなコード制御の利点を強調するのに特に効果的です。
それが失敗した場合は、実行します。
あなたは明らかに自分の状況を特定して修正するための技術的スキルを持っています。問題は人間とプロセスに関連しています。
人々は視覚よりも例に対してはるかによく反応する傾向があるため、私はそれを自分で「修正」することをお勧めします。
最新のソースのコピーを取り、バージョン管理に対応するように再構成し、便利で前向きな構造で新しいプロジェクトを作成します（ブランチの処理方法、サードパーティの依存関係を配置する方法などを検討します）。あなたはおそらくあなた自身の時間にそれをしなければならないでしょう。
次に、同僚と管理職を部屋にドラッグし、show 21世紀のソフトウェア開発の様子を示します。現在のシステムの障害を説明し、新しい構造でどのようにして障害が解消されるかを示します。
また、自分をソースのキーパーとして設定する必要があります-気になるのはあなただけなので、人々に（技術的または心理的手段を問わず）固執するように強制するのはあなた次第です。計画。 onlyが顧客に提供するものが、ソース管理外のビルドマシンからのものであることを確認します。ルールを破って大混乱を引き起こす儀式的な屈辱的な人々。ドーナツで彼らに賄賂を….
それがすべての努力のように思える場合（他のほぼすべての回答で述べられているように）-別の仕事を取得します。彼らはあなたの時間の価値はありません。
誰かがファイルの異なるバージョンとその違いを確認する機能を望まないのはなぜですか？ブランチや複雑なものはすべて忘れてください。彼らは基本さえも理解していません。テスト環境で最も基本的な変更を行わずにプロダクションファイルを直接変更するのは非常識です。私は何人かの個人と仕事をしたことがありますが、ありがたいことに同じプロジェクトに取り組んだことはありません。
あなたの同僚は怠惰になるには愚かです。それは時間の無駄です。あなたが望むことができるのはあなたの上司を訓練することだけです。彼らはあらゆる形態の管理を好むので、経営者はソース管理を好むべきです。彼らに重要性を感じさせます。他をねじ込みます。あなたは彼を置き換えることができないので、リーダーを修正することはあなたの唯一の希望です。他の有能な開発者とのネットワーキングを開始し、あなたがオープニングを持っているときに彼らをあなたのチームに参加させるか、彼らに彼らの店で雇ってもらうようにしてください。
ステップ1-無能なマネージャーを解雇する！
ステップ1を実行できない場合は、マネージャーがデプロイメントをソース管理から取得したスクリプトのみに限定するようにしてください。開発者（製品のプロダクション権限を持たない方がよい場合は、ステップ1を参照してください）をデプロイしたい場合は、ソース管理から取得する必要があります。これにより、C＃コードだけでなく、データベースなどにソースコントロールを最初に使用したときに、ソースコントロールを使用しないという問題が解決されました。
あなたの説明から、状況に1つ以上の問題があるようです-開発チームが制御不能であるか、不良なソース管理ソリューションが実装されています。どちらの方法でも、ソース管理ソリューションを使用するのは開発チームの責任です。運用サービスでソースコードを直接変更すると、問題が発生するだけです。
私の経験から、すぐに実行する必要がある最初の手順は、ソース管理を運用サーバーと同期させることです。このステップは、プロダクションコードのコピーを取り、それをチェックインするだけの簡単なものです。製品コードは、おそらくチームが開発しているベースです。このステップは、既存のソース管理システムに浮かんでいるコードとのマージによって強化する必要があるかもしれません。コードは、開発から統合/ QA（またはその両方）に流れ、次にステージまたはステージ/本番に流れます。
次に、経営者はソース管理の使用を義務付ける必要があります。簡単に言うと、ビルドがソース管理システムからのものではない場合、コードは本番環境にデプロイされるべきではありません。本番環境へのアクセスはサポートチームのみに制限する必要があり、本番環境の問題をトラブルシューティングするために開発者に限定的なアクセス権を付与する必要があります。開発者は通常、コードを本番にホットデプロイしないでください。特に開発者にプレッシャーがかかっている場合は、本番環境で問題が発生する可能性があります。
経営陣はここで問題をより適切に処理する必要があります。コードが直接prodに適用されている場合（およびソース管理に入らない場合）は、開発を維持することはほぼ不可能です。
これは、悪い習慣が広まっているために修正することが実質的に不可能になったプロジェクトの良い例です。修正するにはフリーズが必要になるため、中断することなくすべてをクリーンアップできます。残念ながら、そのようなプロジェクトは通常（明らかな理由により）バグが多すぎて数か月間凍結できず、重大なバグは1日おきに修正する必要があります。
ダーティバージョンはこれらの毎日のバグ修正で処理されていますが、クリーンバージョンを作成するためにプロジェクトをフォークしたくなるかもしれません。しかし、最も可能性の高い結果は、「クリーン」バージョンが終了した数か月後、フォーク以降にどのバグ修正と変更が取り入れられたのか誰もあなたに伝えることができないということです加えた変更に関する記録を保持します）。クリーンバージョンは古く、ダーティバージョンはまだ機能するので、どうなりますか？クリーンバージョンは破棄されます。
明らかな新しい仕事を見つける以外に、私は答えが上記のすべてであると思います。
最初に管理に行き、ソース管理への移行とその使用の強制に参加させます。次に、サーバーで直接作業することを意味する場合でも、物事を実行し続けるために何をする必要があるかを理解します。すべてをソース管理で取得するプロセスを開始します。
別のオプションは、最新のものがサーバー上にあることを確認し（関係なく実行する必要があります）、最新のものから新しいリポジトリーをすべて開始することです。あなたは歴史を失うでしょうが、この時点でそれは小さなジャガイモです。
自分の健全性のために、変更を追跡できるように、自分のマシンにGitまたは別のDVCSを設定することをお勧めします。同僚の変更をリポジトリに頻繁にインポートします。可能な限り競合を解決します。これはあなたの同僚の狂気からあなたを部分的に守ります。
あなたは、管理者が開発者がソース管理を使うべきだと言ったと述べました。邪魔になりたい場合は、TFSへの変更をチェックし、リポジトリを定期的に公開して、TFSにない変更をすべて破棄することで、これを強制できます。 （独自のDVCSも維持している場合は、2つを同期させておく必要があります。）そのための正当化は、管理者からの注文に従っていることです。同僚が変更の上書きに飽きたら、TFSを使用するように招待してください。また、チェックインされていない変更を破棄し続けます。同僚が容赦するか、解雇されるまで続行します。
本当の問題は、カウボーイコーダーがバージョン管理を使用しないことではありません。実際の問題は、彼らがすでに何らかの方法を選択しており、あなたが彼らのプロセスを変えようとしているということです。選択したプロセスにはバージョン管理が含まれていません。プログラマー自身が問題に気づかない限り、すべてのプロセス変更は困難です。既存のシステムが十分であると感じている場合、別のシステムを課そうとしても無駄です。私たちはボーグです、あなたは同化されます。もちろん彼らはボーグになるために戦っています。
開発以外のサーバーをロックダウンします。構成マネージャーを使用します。タグに対して定期的に識別可能なビルドを実行します。すべての変更セットにタグを付けます（つまり、バグごとに1つの変更セット）。また、各ビルドにタグを付けます。少なくとも開発と本番の間にQAタイプのシステムがあること。正しいビルドタグを使用してQAシステムにビルドします。 「ビルドを壊す」ことに対して彼らに悲しみを与えます。
問題を再現/修正できない状況（プロダクションでのみ表示される）に遭遇したことがありません。はい、私は問題を開発システムで再現するために何時間も費やしました（さらに、それを理解したら、回帰テストに追加できると思います）。
私たちは、これらすべての悪いことをしたカウボーイ請負業者の集まりとプロジェクトを行いました。その後、4週間かけてクリーンアップを行い、上記の方法を実行します。それ以来、プロジェクトはこれらの問題のいずれにも問題を抱えていません。