量産コードのみのSubversion /ソース管理？

私は1年前にコンピューターサイエンスの大学を卒業し、現在は小規模なWeb開発会社（私と他の1人の開発者、マネージャー、カスタマーサービス、テスター）で働いています。始める直前まで、ソース管理システムはありませんでした。現在、SVNの実装を徐々に始めていますが、他の（シニア）開発者（以下、Joeと呼ぶ）は、SVNリポジトリにコミットする必要があるコードは、本番用としてテストおよび承認されたコードのみであると主張しています。つまり、大規模なプロジェクトでは、一度に数週間以上コミットが行われない可能性があります。

これは通常の習慣ですか？次のようなソース管理の多くの利点を失うように思えます。

• プロジェクトの進捗状況をきめ細かく追跡
• 問題が表示され解決されたときの問題の追跡
• ミスを簡単にロールバック
• コードの簡単なバックアップ。ワークステーションがダウンした場合でも多くを失うことはありません
• ここで説明するように、リビジョンを実行可能ファイルにスタンプすると仮定すると、どの生産サイトでどのコードが実行されているかを正確に識別しやすくなります。
• 簡単なコラボレーション（チームワークは行いませんが、すべてソロプロジェクトです）
• 等。

編集：歴史的に、この会社には真のチームワークがなかったことを強調する必要があります。2人の開発者が別々のプロジェクトに取り組んでいます。また、多くのプロジェクトは小規模であるため、数週間で完了することができます。そして、同社は10年以上ビジネスを続けており、ソース管理なしで順調に進んでいます。通常、プロジェクトは予定時間内に完了します。

プロジェクトが予定時間内に完了した場合、クライアントが満足していると想定しても安全ですか？:)

同社は新しいタイプのプロジェクトにも着手し始めており、成長する痛みや「変化する痛み」を経験しているようです。ここで起こっていると仮定することがたくさん...私と一緒に耐えてください！

コードの編成と制御があなたとあなたのチームを内部で助けることができると確信しているなら、SVNは私見と見なされるべきです。このルートを実際に使用して、会社がより高品質の製品を製造できるようになり、顧客がより幸せになれば、ボーナスポイントを獲得できます！

経営陣との闘争が緊張した職場環境を作ると思われる場合は注意してください。事実は、所有者が会社を作ったということです。それだけでなく、彼らは成功した会社を作りました。彼らはギャンブルが得意なので、大当たりすることはまずありません。

敬意を払ってください、そうすればあなたは聞かれるかもしれません。

うまくいけば、結果としてより効率的で幸せなチームになります。私の経験では、フラストレーションのある管理ではこれを得るのは困難です。

ジョーはかなり間違っています。これで、検証済みの本番用のコードを表す「クリーンな」ブランチが1つあるという引数を作成できます。しかし、ものの準備が整うまでソース管理を使用しないのは、率直に言って自滅的です。ジンなしでマティーニを作ろうとするようなものです。

「シニア」は実際には非常に未熟です。コンパイル可能なコード（およびテストがある場合はテストに合格）は、ソース管理にコミットする必要があります。ソース管理は、コードを共有してソフトウェアを段階的に構築するための中心的な資産です。

良い点は、生産コード（最後の安定バージョン）を分離することですが、そのような場合、ソース管理システムにはタグ/ラベルやブランチなどの機能が含まれます。

誰かが2〜3日以内に何もコミットしないと、チームは非常に疑わしくなります。それは彼にいくつかの問題があり、おそらく助けが必要であることを意味しています。ソース管理のもう1つのポイントは、通常定期的にバックアップされることです。これは開発マシンには当てはまりません。ディスクがクラッシュすると、数週間作業が失われます。

Joeが正しいか間違っているかという質問はさておき（ところで、彼は間違っています）、GitやMercurialのような分散バージョン管理システムを使用した場合、妥協点に達する可能性があるようです。

そうすれば、あなた自身と他の開発者はローカルリポジトリで作業し、ソース管理に頻繁に変更をコミットしますが、「本番用としてテストおよび承認される」まで「本番」リポジトリに変更をプッシュしません。数週間にわたって作業したすべての完全な履歴があり、Joeには、本番の準備ができていると祝福された変更の履歴しかなかった、手つかずのリポジトリがあります。

あなたがリストしたまさにその理由のために、それは意味をなしません。これは、バージョン管理を使用する利点のないバージョン管理を使用するようなものです。

Joeは、ソース管理システムがソースコードのプロダクションリリースの優れたバックアップではないことを理解していないと思いますが、将来の自己や同僚のためにコードの進行と成熟の小さなステップに言葉をかけることでプログラマーに役立つツールです。おそらく、ジョーは他の人のコードを使用してチームで作業することに慣れていないのでしょうか？

「なぜこのコード行が追加されたのか」と考えたことはありますか？それを導入したコミットを見つけて、コメントを参照してください。本番に行くときにのみコミットする場合、コメントはあなたにとって役立つほど具体的ではありません。

また、SVNよりも強力なツールを使用することをお勧めします。Joel Spoelskyによるhttp://hginit.com/で、可能性に関する優れた紹介を見ることができます。

彼は水銀を使用しており、最近はいくつかの候補があります。Gitは非常に強力であると考えられており、https：//github.com/には非常に便利なツールがいくつかあり、無料のスターターアカウントを提供しているので、実際に試してみることができます。

ジョーはSVNを知っているようには見えません。ブランチ、タグ、およびトランクについて調べてみてください...タグはジョーが望むものと一致しています。SVNのベストプラクティスに関するいくつかの読書は害になりません

SVNを使用したことがないので、この手順がどうなるかわかりません。ClearCaseを使用しています。ここでのプラクティスは、各開発者が独自の開発ブランチを作成し、テストを開始する準備ができたらマージする統合ブランチと、統合およびテスト済みコードの1つ以上のリリースブランチを作成することです。

Joeはハッカーであり、開発者ではありません。彼は非常に良いハッカーのように聞こえますが、リビジョン管理の使用方法については間違っています。それではどうすればいいですか？

あなたの組織はSVNに投資しているように思えますが、Joeに挑戦してSVNサーバーへのドル投資を無効にすることは、あなたのキャリアを制限することになります。GITリポジトリをセットアップし、git svnインターフェースを使用して希望どおりに動作します（これはすべてフリーソフトウェアであり、セットアップには1時間から1日かかります。すべてワークステーションで実行できます）。ジョーでワークフローをソーシャル化します-彼は「汚染されていないSVNリポジトリ」信念システムを保持し、隅にある高価な白い象（およびエゴ）に対する信頼性を維持できます。

短期間のうちに、Joeがあなたの仕事を見て、同じことを始めてくれることを期待しています。1〜2年で、SVNサーバーはGitリポジトリになります。

上記の議論でジョーを説得しようとすることができます。これがうまくいかない場合は、あなた自身の開発作業のためにローカルでSVNを使用し、いつかJoeがそれを拾うことを期待してください。あなたが議論で彼らを納得させることができないなら、あなたが納得したことをして、彼らが働くことを彼らに示してください。分散アプローチの一種ですが、既存のツールを使用します。

ここで@ Carson63000をエコーし​​、この態度を以前に見たことがあると言いますが、これは主にVCSの恐ろしい分岐/マージ機能が原因です。各リリースのタグを使用して、テストをコンパイルしてパスするブランチを作成することは優れたアプローチですが、他のコードがコミットされないという点には従わないでください。DVCS全般、特にGitを使用すると、分岐が簡単で一般的な操作になり、このワークフローでの困難が大幅に軽減されます。

バージョン管理システムがタグをサポートする理由は、認定コードにタグを付けながら、毎日の作業をコミットできるためです。プロダクション品質のコードがある場合はいつでも、タグを格子に入れて完了です。顧客が持っているものを手に入れるために戻る必要がある「時間」の正確なポイントを知っています。また、コードのさまざまなバージョンをいつでも確認して比較できます。このようにして、ソース管理データベースにあるものに満足することができます。私が働いている会社で働いており、100人の開発者がいて、全員が同じプロジェクトに取り組んでいます。それはあなたにとっても間違いなく機能します。

本番環境に配信する準備ができているバージョン管理システムにのみ物を保存することは非常に一般的です。これは、ディスクストレージがメガバイトあたり数百ドルかかり、すべてを保存するのが非常に高価だった昔から、何十年も歴史的に行われてきた方法です。

物事を行うための最良の方法とはもはや考えられていませんが、多くの古いバージョン管理システムがまだ使用されているため、他のことを行うことが不可能ではないにしても困難であるため、人々がまだそれを行う理由を完全に理解できます各リリースは（または、むしろ、戻る必要がある場合、各ファイルのタグをチェックすることなく、リリースが何であるかを知る方法はありません。古いものを戻す唯一の方法がある複数のリポジトリを見てきました。リリースは、そのリリースのソースコードとバイナリを含むzipファイルをリポジトリから取得することでした）。