私は1年以上前にこの質問をしましたが、その間にチームにさらに多くの人を追加し、WordPressで非常に多くのサイトを開発しました。他の人に役立つかもしれない場合に備えて、私たちのプロセスを見ていきたいと思いました。
Gitのすべて
これは私が質問をしているときでさえ行っていたことでしたが、この点を指摘するのは良いことです。Gitを使用することで生産性が向上しただけでなく、集団でのロバを数回節約できました。
サイトの構造的な大規模な改修を行い、クライアントから改修の承認を得て、改修されていないバージョンのマイナーな更新を行う必要がありましたか?Gitがそれを実現しました。この設定を説明するには少し時間がかかりますが、基本は新しいブランチを作成し、そのブランチをサーバーにプルし、サブドメインをそのブランチにアタッチすることです。
また、Gitによって保存されました。もちろん、変更をロールバックできますが、これは素晴らしいことですが、ファイルの古いバージョンを戻すこともできます。これは、クライアントが「サイトのこの部分が約1年前にどのように機能したか覚えていますか?それを戻すことができますか?」前。
これらの点に加えて、必要なファイルなしで立ち往生することもありません。どのマシンからでも最新バージョンのサイトをいつでもプルダウンして、変更を開始できます。
Gitを使用して展開する
Media TempleでWordPressホスティングを行っており、本当に気に入っています。彼らは最も安いプロバイダーではありませんが、彼らのサービスは優れており、彼らのサーバーは本当にうまくセットアップされています。また、デフォルトでGitも提供します。つまり、サーバーをGitリポジトリとして設定し、SFTPを使用する代わりにその方法で変更をプルできます。また、サーバーで作業を行うことで上書きされる危険性がないことも意味します(これらの変更は単にマージしてプッシュバックできるため)。
BitBucketをGitホストとして使用しているため、ここでは少し余分な作業が必要です。まず、.ssh / configファイルを使用ssh sitename
して、サーバーへのログインなどを入力できるようにします(パスワードなしのSSHも使用しているため、非常に簡単です)。また、必ずsshパスフレーズを使用するようにします(Mac OS Xでは、パスフレーズをKeychain.appに保存できるため、これが非常に簡単になります)。最後に、ForwardAgent行を、プルしたいホストの.ssh / configエントリに追加します。これは、各サーバーの公開キーではなく、BitBucketで各人のSSH公開キーのみが必要であることを意味します。また、.git
ディレクトリをパブリックHTMLディレクトリの1つ上のディレクトリに保持するようにします。
自動化されたデータベースダンプ
サーバーが運用モードになると、念のため、データベースを自動的にバックアップします。
誰もが独自のwp-configを持っています
独自のローカルデータベースのユーザー名とパスワードがあり、異なる名前とサービスメカニズムを使用できるため、それぞれ独自のwp-configファイルを保持しています。これらはそれぞれGitのような名前でGitに保存され、wp-config-gavin.php
その構成を使用する場合、シンボリックリンクしますwp-config.php
(.gitignoreを使用するGitでは無視されます)。
これによりsiteurl
、wp_options
データベーステーブルのオプションを次のようにオーバーライドすることもできます。
define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');
これにより、WordPressはサーバーの場所をデータベースで確認できなくなり、ローカルインストールとサーバーインストールの場所に奇妙な違いがないことを意味します。
wp-config.phpファイルに関する最後の注意点:必ず公開HTMLディレクトリの上に保存し、Webユーザーのアクセス許可を読み取り専用にします。これにより、WordPressの保護に大きな違いが生じます。
データベースの問題
最後に、問題の肉。
私が受け入れなければならなかったのは、WordPressを使用するとき、データベースの変更を「マージ」する良い方法がないということです。代わりに、これを解決するための行動ルールを開発する必要がありました。ルールはかなり単純で、これまでのところ私たちに役立っています。
開発中、サイトを「所有」する人が一人います。通常、その人がセットアップを行います(ホスティングパッケージを取得し、Basecampプロジェクトを開始し、デザインをスライスします)。その人が妥当な位置に来たら、WordPressインストール用のデータベースをダンプしてGitに入れます。その時点から、開発を行うすべての人がそのデータベースダンプを使用し、所有者のみがデータベースに変更を加えます。
サイトの構築が少し進むと、サイトはサーバーに配置されます。その時点から、サーバーのデータベースは標準になります。全員(所有者を含む)は、サーバー上ですべてのデータベースの変更を行い、ローカルの開発とテストのために変更をプルダウンする必要があります。
このプロセスは完璧ではありません。開発中に誰かがWordPressバックエンドをローカルで変更する必要があり、本番環境でそれらの変更を再度行う必要がある可能性があります。ただし、そのようなことはまれであることがわかり、このプロセスは非常にうまく機能します。