バージョン管理のコードはどのように保存する必要がありますか？

バージョン管理のコードはどのように保存する必要がありますか？

開発者に優しい？プログラマーは、多くの変更を行うことなく、エディターから最新のものをすぐに実行できるようになりますか？（dev DB..etcを指す構成ファイルなど）

または

それは生産に適しているべきですか？ソースは本番環境に簡単に展開できる方法である必要があり、開発者が最新版を取得する場合、開発ニーズに従って変更を実行する必要があります。

選択する理由 両方でなければなりません。

開発環境は、チェックアウト、オープン、ビルド、実行、デバッグを行うのと同じくらい簡単になるように構成する必要があります（例：絶対パスなし！）。これは、コンパイルディレクティブ、構成クラス+依存性注入、またはASP.NETのperso.configなどのトリックで簡単に実行できます。

自動化されたビルドスクリプトは、特定の本番構成、クリーンアップ、パッケージングなどを処理するために十分にカスタマイズする必要があります。

人々が貢献することが期待されるオープンソースプロジェクトの場合、私は開発者に優しいものを選ぶでしょう。

オープンソースプロジェクトに関する私の最大の嫌悪は、リポジトリがコードをビルドするために必要なすべての依存関係を含むことはめったにありませんが（実際的または法律上の理由で）より重要なのは、必要なバージョンです。（そしてできればどこから入手するか）

目的のプロジェクトをビルドするために、他のいくつかのプロジェクトを取得してコンパイルするのに半日以上かかることがあります。

もちろん、これはWindowsでの開発にのみ関係します。

両方ですが、それはあなたがどのくらい頻繁にあなたの作品を作るかに依存しています。多くのカスタマイズされたアプリケーションでは、展開は手動でローカルに行われます。一方、開発者はプロジェクトの規模にかかわらず、常にコードをコミットします。私の意見では、開発者がバージョン管理を正しく使用できることを確認することがより重要であると考えています。

それは生産にやさしいはずです、そうでなければ自動化されたビルドを維持することは問題です。

仕事をやりやすくするために、私はすべて摩擦を下げることを望んでいますが、障害モードも考慮する必要があります。

ソースリポジトリバージョンが常に本番用に構成されている場合、システムを実行する前に開発者が再構成に失敗した結果はどうなりますか？実動に対してコードを実行する開発者。

開発者がプロ​​ダクションをランダムに変更する方法に他のハードルがあるかどうかに関係なく、それを促進する障害モードを構築することは危険に思えます。

コミットされたコードに含まれるデフォルト値は常に安全であるべきだと提案します。必要に応じて、プロダクション構成ファイルもソース管理にチェックインします-私はほとんど常にそうします-しかし、「ライブではない」どこかに保管します。

私は生産にやさしいために努力する傾向があります。ビルドをクリーンに保ち、無関係な設定が本番環境に移行するのを防ぎます。

QAと本番の変更を自動化するスクリプトを備えた、間違いなく開発者に優しい。

なぜ展開可能なコードや開発者向けバージョン用のブランチ（使用するバージョン管理に依存します-Gitを使用します）を持たないのですか？これは非常に良く聞こえ、セットアップもそれほど難しくありません。

変更を処理してコミットし、デプロイ可能なバージョンにマージできます。