私はGitとBeanstalkを使ってWordPressをローカルに開発し、次にBeanstalkのデプロイメントプロセスでプロダクションサーバにデプロイします。 しかし、プロダクションサーバで行われた変更をローカルの開発/ gitリポジトリに同期化するにはどうすればよいですか？誰かがプラグインをインストールすると、サーバー上の変更が発生します。これらの変更をローカルに戻す方法はありますか？Git、Beanstalk、WordPressの究極の展開アプローチ
初心者の皆様のご理解に感謝します。ありがとう！
私はCMSを実行しました。私がコメントで述べたように、私はmanojldsの助けを借りて自分のワークフローセットアップを得ました。私は、ユーザーが作成したコンテンツを手助けしたいと考えて、実装を拡張したかったのです。
私はリモートリポジトリとしてgitoliteをセットアップしました。それは揺れる。
当社の分岐モデルは、コンテキストとして、ワードプレスで、そのように動作します：、
master - # this is the _vanilla_ install of wordpress with no modifications
prod - # the branch that the production server pushes/pulls to
dev - # dev environment pushes/pulls to, in our case a server
alpha - # really early development, ideas, etc - my personal branch that i work on mostly
features (opt) - # as needed, I'll make feature branches then merge them into the other branches.
私たちのprod、一日あたり約40〜45異なる静的ファイルを処理し、自動的に追加するcronを持っている/コミットし、ユーザーに変更ファイルおよびデータを毎日更新します。それはユーザーベースの変更をすべて取り上げ、プラグインのインストールを（あなたの場合は）拾うでしょう。あなたのインストールの履歴があるので、これは素晴らしいことです。
コードベースの実際の変更は、通常alphaで調べられ、その後devにマージされます。私たちはdevブランチへのpush、devサーバが自動的にpullsをコミットするときにいくつかのフックを作成しました。
開発環境でテストした後、ローカルのプロダクションブランチをリモコンと同期させます。これは、前述のように毎日ユーザーコンテンツをコミットします。次に、mergeまたはcherry-pickを製品にコミットし、次にpushをジトライトにプロットします。その後、製品サーバーpullsと皆が満足しています。
これは多くの作業のようですが、実際には、特にフックスクリプトの後では非常に効果的です。私はまだ展開を調整中です（例えば、alphaブランチを一掃し、dev/featureをローカルで処理できます）。実際には、プロダクションサーバーのスナップショットを毎日作成するのに素晴らしいボーナスを得ています。いつでもすべてのブランチを同期することができます。
また、あなたのmasterブランチについては、これをWordPressのバニラインストールとして残しておいてください。実際に新しいバージョンのアップグレードを簡単にテストできます。マスタをチェックアウトしてからアップデートを実行し、ゆっくりとカスタマイズを統合できます。
Thx - これは生産から開発、そして生産に戻るサイクルを完了させるようです。ここの鍵は、私が理解しているように、本番サーバーからどこかのレポにコミットすることです。その後、そのレポは開発者に引き込まれ、調査され、その後プロダクションにプッシュされます。私はあなたが言っていることの要点だと思う。 –
あなたは "ユーザーが変更したファイルとデータ"について言及しました。これは、このプロセスを通じてデータベース変更を追跡していることを意味しますか？ –
さて、私たちは静的ファイルを扱っています（WPが行うデータベース駆動型ストレージとは対照的です）。そのため、これらのファイルの変更を具体的に追跡しています。私たちはデータベースをバージョンアップする方法を模索していますが、効率的な方法を見つけていません。ゴーストDBは始めるには良い場所のようです。 – Nic
私の意見では、変更は生産上では理想的ではありません。プラグインをインストールする方法を見て、プラグインをgitリポジトリに追加し、それをprodにプッシュする方法はありませんか？私はおそらく、それをPRODに追加するWordPress UIからプラグインをインストールすることについて話していることを理解していますが、プラグインの内容を取得し、リポジトリに追加してPRODにプッシュする必要があります。
これはまったく不可能な場合は、新しいプラグインがPRODにインストールされているときにプラグインのコンテンツがコミットされていることを確認してから、同期するコンテンツをgit pullにする必要があります。
私が第2段落を理解しているかどうかを見てみましょう：gitをPRODにインストールして、プラグインをインストールした後に、追加してコミットしてください。それから私の地元のレポで、私はプルをする？次に、私はBeanstalkにプッシュし、必要に応じてサーバーに戻ってサイクルを完了します。 –
@manojldsはgitを同様に配備したときに私を助けました。私はここで同意する必要があります。変更はまず開発環境で行われ、_local_プロダクションブランチとマージされた後、prodサーバからプルされます（またはそれを見たい場合は同期されます）。それは理にかなっていますか？ – Nic
私の言う限りでは、実動サーバー上のリポジトリにコミットする必要がある場合は、間違っている可能性があります。プラグインをインストール、設定、テストする開発環境をセットアップすることをお勧めします。安定している場合は、コミットしてWebサイトを再デプロイします。 –
私は簡単な答えは、このプロセスはwordpressで壊れていると思います。 私はまだftpでアクセスしたwordpressが変更されたファイルをrepoに追加して新しいバージョンにすることができる解決策を見つけていません。
私はそれを1分戻してください。私はユーザーの介入なしで意味します。 ftpをドライブとして、そして/またはsnycの生産サイトをトランク内のマシンに戻してから変更をコミットすると、あなたは自分のリポジトリに戻ることができます。
ユーザーが悪い習慣を考えていることをユーザーが行えるようにするWordPressのすてきな機能をすべて削除するのではなく、解決策が必要です。私はBeanstalkを使用しています。プロダクションサーバにデプロイすることに加えて、プロダクションサーバからの変更を自動的にリポジトリに戻して変更を通知するように指示することができます。その後、私は何が起こっているのか、その問題が以前のバージョンから再展開されたのかどうかを調べることができます。
このままでは状況は限定的であり、より多くの作業が必要です。私は自分の自動プルとチェックインのメカニズムを試してみることができると思うが、それは疲れているようだ。もし誰かが（SSHでサーバを走らせる以外に）良い方法を知っているなら、私はその解決策を聞くことに興味があるでしょう。
これは、すでに受け入れられている回答をどのように追加、修正、改善しますか？ –
セキュリティ上の問題ではありませんが、あなたは*良いコピーとしてあなたのレポにコミットしているサードパーティのコードを持っていますか？ –