3

私はGitとBeanstalkを使用してWordPressをローカルで開発し、Beanstalkのデプロイプロセスで本番サーバーにデプロイしています。しかし、本番サーバーで行われた変更をローカル開発/ gitリポジトリに同期するにはどうすればよいですか?サーバーの変更は、誰かがプラグインをインストールするたびに発生します。それらの変更をローカルに戻す方法はありますか?

初心者の理解を念頭に置いて助けていただければ幸いです。ありがとう!

4

3 に答える 3

2

私は CMS を実行しており、コメントで述べたように、manojlds の助けを借りてワークフローをセットアップしました。ユーザーが作成したコンテンツであなたを助けることを期待して、私たちの実装を拡張したいと思いました.

リモートリポジトリとして gitolite をセットアップします。揺れます。

私たちの分岐モデルは、WordPress をコンテキストとして次のように機能します。

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.

1 日あたり約 40 ~ 45 の異なる静的ファイルを処理する製品には、ユーザーが変更したファイルとデータを毎日自動的に追加/コミットする cron があります。これにより、ユーザーベースの変更がすべてピックアップされ、(あなたの場合) プラグインのインストールがピックアップされます。インストールの履歴があるため、これは素晴らしいことです。

コードベースへの実際の変更は通常、アルファ版で検討され、その後開発版にマージされます。push開発ブランチに移動すると、開発サーバーが自動的に新しいコミットを行ういくつかのフックを作成pullsしました。その後、それらは同期されます。

開発環境でテストした後、ローカルの運用ブランチをリモートと同期します。リモートは、前述のように、ユーザー コンテンツのコミットを毎日取得します。次に、製品にコミットするmergeか、 gitolite で製品化します。その後、prodサーバーと全員が満足しています。cherry-pickpushpulls

これは大変な作業のように思えますが、実際には非常に効果的で、特にいくつかのフック スクリプトを作成した後です。私はまだデプロイメントを微調整している最中ですが (たとえば、alphaブランチをほぼ完全に削除して、dev/featureローカルで作業することができます)、実稼働サーバーの毎日のスナップショットを実際に取得することで素晴らしいボーナスを得ることができます。すべてのブランチをいつでも同期できます。

また、あなたのブランチに関しては、master新しいバージョンのアップグレードを実際に簡単にテストできるため、これを WordPress のバニラ インストールのままにしておくことは素晴らしいことです。マスターをチェックアウトしてから更新を実行し、ゆっくりとカスタマイズを統合することができます。

于 2011-08-24T16:24:12.360 に答える
1

私の意見では、理想的には本番環境で変更を行うべきではありません。プラグインを git リポジトリに追加して製品にプッシュすることで、プラグインをインストールする方法を検討できませんか? おそらく、プラグインを WordPress UI からインストールして PROD に追加することについて話していることは理解していますが、プラグインのコンテンツを取得し、リポジトリに追加して、PROD にプッシュする必要があると思います。

それがまったく不可能な場合は、新しいプラグインが PROD にインストールされたときにプラグイン コンテンツがコミットされていることを確認する必要があります。その後git pull、コンテンツを同期できます。

于 2011-08-23T22:16:44.950 に答える
0

短い答えは、このプロセスがワードプレスで壊れているということだと思います。ftp 経由でアクセスする wordpress が、変更されたファイルをレポに追加して新しいバージョンにすることができる解決策をまだ見つけていません。

ちょっと話を戻します。つまり、ユーザーの介入なしです。ftp をドライブとしてマッピングしたり、実稼働サイトをトランク内のマシンに snyc したりして変更をコミットすると、wordpress 実稼働サーバーで起こっていることをリポジトリに戻すことができます。

コーダーが悪い習慣と見なしていることをユーザーが実行できるようにするワードプレスの優れた機能をすべて削除する以外に、これに対する解決策があるはずです。私は Beanstalk を使用していますが、運用サーバーへのデプロイに加えて、運用サーバーからの変更をレポに自動的に追加し、変更を通知するように指示できれば幸いです。次に、何が起こっているのかを比較して、問題がある場合は以前のバージョンから再デプロイします。

現状では、状況は限定的であり、より多くの作業が必要です。独自の自動化されたプルとチェックインのメカニズムを構築することもできると思いますが、それは面倒に思えます。誰かがより良い方法を知っている場合(SSHでサーバーを実行する以外に)、解決策を聞きたいです。

于 2012-03-27T18:14:49.583 に答える