「drush rsync」対「git」を使用して開発->製品をステージングすることの利点

開発作業のために、gitの管理下にあるDrupalサイトをセットアップしました。

これは、マスターのベアGITリポジトリを親とし、変更がさまざまなプロジェクト作業gitクローンで行われ、マスターにプッシュバックされると、更新後のフックがすぐに単一のライブステージングWebサイトに変更をプッシュします（http：/ /staging.loc。）。特別なことは何もない、期待どおりに動作します。

また、サイト "@STAGING"をドラッシュエイリアスしました。場合によっては、変更をステージングサイトから運用サーバーに昇格させたいと思います。

2つの比較的簡単な方法が思い浮かびます：

（1）ステージングサイトが安定しているように見える時点で、マスターリポジトリからのgitチェックアウトとして本番サイトを作成します。

（2）ステージングサイトから本番サイトにdrush rsync+ drush sql-syncを使用します。

どちらも機能させることができます。（2）本質的にDrupal中心/認識であるという事実以外に、drushは、結局のところ、Drupal固有のツールのセットです-2つのアプローチの相対的なメリットは何ですか？

（2）よりも（1）を考慮する必要がある特別な理由はありますか？

どちらの場合も、「すべて」はリビジョン管理の少なくとも1つのインスタンスの下にあります...

私は両方のテクニックを使用しました。どちらも、@ stageでテストした同じファイルが@liveで終了することを保証するために使用できます。rsyncの利点は、運用サーバーに余分なファイル（「.git」など）が残らないことです。私はvpsにrsyncする傾向があり、私が所有するボックス（イントラネットサイトなど）でgitを使用します。

drush rsyncを使用する際の問題は、複数のユーザーがサーバーに変更をプッシュしている場合です。

この例では、1人の人が変更をプッシュしているだけです。

開発者Aが彼女の変更をプッシュし、次に開発者Bが彼の変更をプッシュする場合、Gitで競合を解消するか、開発者Bに競合を解消させます。

私は実際に両方を使用しています。svn / gitとrsyncは2つの異なる目的を果たします。SVN / Gitはソースコントロールのためであり、rsyncかつsql-sync効率的にステージング及びPRODを同期するためのものです。コードの品質の狂気/方法論をさらに詳しく知りたい場合drush rsync @staging @prodは、単純さの点で勝つことは非常に難しく、ほとんどのcontinuous Integration環境に統合するのは恐ろしく簡単です。

個人的には、バージョン管理、展開、さまざまなサーバーコードベースの同期にGitを使用し、次にrsyncを使用してユーザーファイルを移動/同期します（.gitignoreファイルに特定のパスを追加することで無視されます）。