私たちは、既存のコードベースでかなり大きなウェブサイトに取り組み始めたグループです。テストサーバーと本番サーバーがあります。
私たちのアイデアは、プッシュアクセス権を持つ多数の開発者がいるテストリポジトリを用意することです。ほんの少ししかプッシュできない祝福されたリポジトリ。祝福されたレポは常に安定していて、最新の本番バージョンを表しているはずです。
ファイルを本番環境に転送するプロセスを自動化するにはどうすればよいですか?本番ファイルをバージョン管理するのは悪いことですか?このように、祝福されたリポジトリにプッシュすることはデプロイを意味します。しかし、マージの競合があるとどうなりますか?本番サーバーは解決されるまで壊れますか?
簡単に言うと:
プッシュプロセス自体は完全に自動化されている必要があります。カスタムスクリプトがあるかどうか、または「祝福された」リポジトリから本番環境に単純にプルするかどうか。あれは君次第だ。自動化されたプロセスは信頼できるため(手動でファイルをアップロードするのではなく)、何かを自動化する必要があります。
ただし、プッシュプロセスは手動でトリガーする必要があります。更新をプッシュし、自信が持てたら、それをリリース候補としてタグ付けし、テスト環境にプルします(理想的には、本番環境にできるだけ似ています)。 RCがテストされると、プッシュを開始できます。
現在のところ、人間のテスターができることを除いて、他に何も与えることができません。
フィードバックループが比較的大きいという意味で、これは少し遅く聞こえます。ただし、適切なテストを行うには、固定のスナップショットを作成することが重要です。このスナップショットは、24〜48時間(またはプロジェクトのサイズによってはそれ以上)検査されます。反対は、プッシュした直後に多くのバグを見つけ、新しいバグを導入するいくつかのクイックフィックスでパッチを当てようとするシナリオです。
リリースは、既知のバグ(許容可能な重大度)で、未知のバグ(未知の重大度)のリリースよりも優れています。
Capistranoがどのように動作するかを見て、配備について多くを学びました。私は当時RoRを使用していたので、それは論理的な選択であり、作業中のプロジェクトでは動作するようになりましたが、自動更新を実行する方法は非常に役に立ちました。
あなたはそれを直接使用することができる状況にあるかもしれません-それは必ずしもRailsに結び付けられているわけではありません-しかし、そうでなければ、それがふるまう方法は確かに役に立ちます。
使用しているプラットフォームに応じて、本番リリースを自動化するために使用できるツールがたくさんあります。私は.NETショップで働いているため、NAntを使用してきました(ただし、最近はMSBuildがより良いオプションです)。 JavaにはAntが含まれている可能性があります。RubyにはRakeのようなものが含まれています。TeamCityやHudsonのような継続的な統合プラットフォームがあり、リリースの管理に使用できます同じように。
製品コードを別のソース管理リポジトリに直接配置することは見たことも聞いたこともありませんが、それでも確かに機能します。 back2dosが言ったように、キーは自動化することです。ソース管理からチェックアウトしてビルドし、ステージング環境にプッシュしてテストするように設計されたビルドスクリプトがあります。次に、ステージングの動作を確認すると、スクリプトがQAから製品にコピーされます。
私が推奨するのは、そこにあるツールを見て1つ選んでから、選択したツールでうまく機能するプロセスを設計することです。ホイールを作り直しすぎないでください。これは非常に解決された問題です。