ファイルを本番環境に転送する方法は？

私たちは、既存のコードベースでかなり大きなWebサイトに取り組み始めたグループです。テストサーバーと本番サーバーがあります。

私たちのアイデアは、プッシュアクセス権を持つ多くの開発者がいるテストリポジトリを用意することです。そして、ほんの少ししかプッシュできない祝福されたリポジトリ。祝福されたレポは常に安定していて、最新の本番バージョンを表しているはずです。

ファイルを本番環境に転送するプロセスを自動化するにはどうすればよいですか？本番ファイルをバージョン管理するのは悪いことですか？このように、祝福されたリポジトリにプッシュすることはデプロイを意味します。しかし、マージの競合があるとどうなりますか？本番サーバーは解決されるまで壊れますか？

簡単に言うと
、プッシュプロセス自体は完全に自動化されている必要があります。カスタムスクリプトがある場合でも、「祝福された」リポジトリから本番環境にプルするだけでもかまいません。あれは君次第だ。自動化されたプロセスは信頼できるため（手動でファイルをアップロードするのではなく）、何かを自動化する必要があります。

ただし、プッシュプロセスは手動でトリガーする必要があります。更新をプッシュし、自信が持てたら、それをリリース候補としてタグ付けし、テスト環境にプルします（理想的には、本番環境にできるだけ似ています）。RCがテストされると、プッシュを開始できます。
今日の時点では、人間のテスターができることを他に何も与えることができません。

フィードバックループが比較的大きいという意味で、これは少し遅く聞こえます。ただし、適切なテストを行うには、固定のスナップショットを作成することが重要です。このスナップショットは、24〜48時間（またはプロジェクトのサイズによってはそれ以上）検査されます。反対は、プッシュした直後に多くのバグを見つけ、新しいバグを導入するいくつかのクイックフィックスでパッチを当てようとするシナリオです。
既知のバグ（許容可能な重大度）を持つリリースを作成する方が、未知のバグ（未知の重大度）を持つリリースよりも優れています。

Capistranoがどのように動作するかを見て、配備について多くのことを学びました。私は当時RoRを使用していたので、それは論理的な選択であり、作業中のプロジェクトでは動作するようになりましたが、自動更新を実行する方法は非常に役に立ちました。

あなたはそれを直接使うことができる状況にあるかもしれません-それは必ずしもRailsに結び付けられているわけではありません-しかし、そうでなければ、それが振る舞う方法は確かに役に立ちます。

使用しているプラ​​ットフォームに応じて、本番リリースを自動化するために使用できるツールがたくさんあります。私は.NETショップで働いているため、NAntを使用してきました（ただし、最近はMSBuildがより良いオプションです）。JavaにはAntがあり、おそらく他にもあります。RubyにはRakeのようなものがあります。さらに、リリースの管理にも使用できるTeamCityやHudsonなどの継続的インテグレーションプラットフォームがあります。

別のソース管理リポジトリに直接prodコードを含めることは見たことも聞いたこともありませんが、それでも確かに機能します。back2dosが言ったように、キーは自動化することです。ソース管理からチェックアウトし、ビルドし、ステージング環境にプッシュしてテストするように設計されたビルドスクリプトがあります。次に、ステージングがどのように機能しているかを確認すると、スクリプトがQAから製品にコピーされます。

私が推奨するのは、そこにあるツールを見て1つ選んでから、選択したツールでうまく機能するプロセスを設計することです。ホイールを作り直しすぎないでください。これは非常に解決された問題です。