web-dev-qa-db-ja.com

Git/GitHubは良いWordPress展開ソリューションですか？

私は現在WordPressをローカルで開発しています。Gitを使ってコードをGitHubにコミットしてから、サーバーにSSHで接続し、コードを更新するために "git pull"を実行しています。これはWordPressサイトへのコード展開に適したオプションですか（この場合、明らかに私のサーバーへのルートレベルのアクセス権があります）。この場合、どうすればGit/GitHubを最大限に活用できますか？

deploymentgitgithub
66
Matt

私はこれにgitを使っていて、それが本当にうまくいっているのを見つけます。いくつかの提案：

  • アップロードディレクトリ（wp-content/uploads）ディレクトリを.gitignoreファイルに追加します。
  • 開発システムでWebサーバーとデータベースサーバーを実行して、変更を本番環境にプッシュする前にローカルでテストできるようにします。
  • データベース接続設定をdevとprodの間で一貫性を保つようにするか、開発用のワードプレス設定が本番用の設定を上書きしないようにwp-config.phpを.gitignoreファイルに追加してください。
  • Wordpressの管理インターフェースを使ってプロダクションシステム上のプラグインを更新することは避けましょう - せいぜいあなたのgitコピーはあなたがプッシュ/チェックアウトするとすぐにあなたが更新したプラグインを上書きするでしょう。開発システムの管理インターフェースを使用して更新を行い、コミット、プッシュ、および本番環境でのチェックアウトを行います。

  • あなたの更新をあなたのウェブサーバーを通してワードプレスを公開するのに使うディレクトリ（例えばpost-receive）に自動的にチェックアウトするためにgit /var/wwwフックを追加することを検討してください。これにより、ファイル自体をチェックアウトすることだけが可能になり、gitメタデータがWebサーバーのドキュメントルートに入り込むのを防ぎ、また受信許可フックにアクセス許可の変更を追加して、アクセス許可を毎回一貫させることができます。例を以下に示します。

    #!/bin/sh
unset GIT_INDEX_FILE
# the directory your web server serves wordpress from 
export GIT_WORK_TREE=/var/www/example.com/
# the local directory where your remote git repository sites
export GIT_DIR=/home/git/repos/example.com.git/
# below user is for debain - you want the user and group your webserver uses
Sudo git checkout -f
Sudo chown -R www-data:www-data $GIT_WORK_TREE
Sudo chmod -R 755 $GIT_WORK_TREE
Sudo chmod 600 $GIT_WORK_TREE/wp-config.php
Sudo chmod -R 775 $GIT_WORK_TREE/wp-content
59
James Hebden

私はCapistranoをセットアップすることを強くお勧めします - それは最初のうちの少しの先行作業ですが、その後、あなたは新しいセットアップのためにそれを簡単に使うことができます。

主な利点は

  • あなたのデスクトップから展開できること。それほど多くは聞こえないかもしれませんが、あなたのリモートサーバにSSH接続して、そしてgit pullをすることはまだお尻の痛みです。
  • 必要に応じて以前のバージョンに簡単にロールバック
  • ステージング/運用環境へのセットアップ展開など、クールなことができるようになりました。

設定方法を説明するため、一連のcapistranoスクリプトを追加します。

キャップファイル 

require 'railsless-deploy'
load 'config/deploy'`

deploy.rb 

set :stages, %w(production staging local)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

set :application, "" # your application name - used to set directory name

set :scm, :git
set :repository, "" # use the ssh repo access line you get from the provider eg [email protected]:name/repo.git
set :deploy_to, "/var/www/#{application}" #this is the root site folder on the remote server
set :deploy_via, :remote_cache # get directly from repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# makes capistrano ask for Sudo password or other remote inputs
default_run_options[:pty] = true

namespace :tasks do
    task :fix_links  do
        run "ln -nfs #{shared_path}/uploads #{release_path}/wp-content/uploads"
        run "ln -nfs #{shared_path}/wp-config.php #{release_path}/wp-config.php"
      run "ln -nfs #{shared_path}/blogs.dir #{release_path}/wp-content/blogs.dir"
      run "ln -nfs #{shared_path}/.htaccess #{release_path}/.htaccess"
      run "Sudo chown -R www-data.www-data #{release_path}/"
    end
end

after "deploy", "tasks:fix_links"

そして最後に、サンプル環境ファイル（あなたが多段階gemを使うなら、あなたはあなたの環境の各段階、例えばローカル、ステージング、プロダクションのためにこれらのうちの1つを持つことができます）

config/local.rb 

server "", :app  #hostname
set :branch, 'develop' #choose branch to deploy
set :use_Sudo, false #don't use Sudo

set :deploy_to, "/var/www/#{application}" #overwrite default path to deploy to

これらのファイルは調整しなければ機能しないかもしれません、そして、あなたはいくらかの基本的なCapistrano知識を必要とするでしょう、しかしうまくいけば何人かの人々を助けるでしょう。

これは私がCapistranoとWordPressでうまくいった私が使った最初のチュートリアルでした： http://theme.fm/2011/08/tutorial-deploys-wordpress-with-capistrano-2082/ /

22
anu

私は実際にこのトピックに関してWordCampのプレゼンテーションをしました。私自身を繰り返すのではなく、 これはそのスクリーンキャストです および これは非常に単純なデプロイメントスクリプトです 私が説明した内容に付随するものです。

要するに、私はGitHubを使ってレポをホストし、ウェブフックを使ってgit refに基づいて変更をデプロイします。これにより Vincent Driessenのgit分岐モデルを使用することができます そして無制限のWebヘッド、ステージングサーバー、テストサーバーなどを持つことができ、すべて自動展開されます。 wp-config.phpをバージョン管理下に置く一方で、別々のdev/productionバージョンを維持することをカバーします（ファイルの名前を変更しシンボリックリンクすることによって）。

9
Matthew Boynes

私はこの質問が少し古いことを知っていますが、ここでは答えとして見ていないので、シングルサイトのgitベースのセットアップと展開で通常行うことを共有したいと思いますデバイス、場所、および複数の開発者（すべてgitで一般的な独自のローカルリポジトリを持っています）.

私は心から次の設定を提案できます：

また、概要を説明します（頭を包むために2つ目のリソースが必要な場合）。

基本的には（少なくとも3つのリポジトリで）動作します：

  1. ウェブサイトをgitのライブホストに配置し、
  2. ライブホストで新しい bare git repository を作成します。
  3. そして、ベアリポジトリからローカル開発gitリポジトリに分岐します。

作業が完了したら、クローンを作成したリモートベアリポジトリに対してプッシュします。ベアリポジトリには、ライブリポジトリと同期するためのフックがあります（上記のコードではprimeと呼ばれます）。

リポジトリのWordpress固有の設定として、私はこれを.gitignore持っています：

# uploads are data, excluded from source tree
wp-content/uploads/

残りを含む。プラグインとテーマの構成は、バージョン/構成の管理下にあります。これにより、変更を追跡し、コードをライブで使用する前にbeforeを確認できます。また、自分の変更により、リモートツリーに対してより簡単にマージできます。これは、 Githubで利用可能なWordpressコア に対して特に役立ちます。

これは、私のWordpressニーズのほとんどにうまく機能します。裸のレポは、競合する変更をプッシュすることを防ぎます。また、ライブサイトを更新する前に、最初にリモートコピーに同期します。つまり、通常、ライブサイトの更新は非常に高速です。フックがあるため、必要に応じてWordpress updateフックを後で呼び出すこともできます。

これをGithubフックでどれだけ改善できるかを実験していなければ、コードはGithubではなくローカルバージョン管理下にあるため、通常は必要ありません。

このようなシステムを初めてセットアップするには、リモートホストで使用可能なすべてのツールがあるかどうかを評価するために少し時間をかける必要があります。

  • SSHアクセス
  • GIT
  • ファイルとサブディレクトリを配置できるプライベートディレクトリ（例：ベアgitリポジトリ用）

最初のセットアップ時間は、1時間から2時間以内に可能になるはずです。環境全体で、最初にプッシュを公開します。

ホストによっては、.gitディレクトリをWebアクセスから保護することもできます。サブディレクトリ内にWordpressを配置する.htaccessコードの例は次のとおりです。これにより、リポジトリ内のスペースがオンラインで公開されなくなります（有用）。

Options -Indexes

# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$

# mask 403 on .ht* as 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

つまり、publicディレクトリ内にないものはすべてオンラインではありません。 publicディレクトリ内にwordpressコードベースを配置できます。たとえば、.htaccessの場合は、次のようにする必要があります。

RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

これにより、publicへの直接アクセスが防止されます。この部分。htaccess-fooの概要は次のとおりです。 。htaccessへのリクエストは、403ではなく404を返す必要があります 。環境変数については、環境で機能するかどうかをテストする必要があります。また、それをバージョン管理下に置くかどうかを決める必要があります。

ホスティングをより細かく制御できる場合は、ここでより多くのことを行うことができます（異なる/より最適化されます）。上記の例は、一般的な共有ホスティング環境を対象としています（GITを提供し、一部のユーザーは、まあ、私は通常、ホスティング業者にそのようなものを提供するよう依頼します。

マイナス面として、これには他の回答でも概説した共通の問題がいくつかあります。私が誇りに思っていないことの1つは、データベースホストが開発コピーを指すように、開発ホストにホストファイルの変更を与えることです。したがって、1つのデータベース構成を保持できます。本当にクールなESPではありません。資格情報のため。

自動バックアップ

ただし、通常はここではあまり気にしませんが、代わりにリモートシステムで毎日バックアップを実行します。これは簡単で安価で、Wordpressインストールとファイルアップロード、データベースおよびgitの両方を復元できます。レポ。また、バックアップコマンドについては、私は完全に大丈夫ではないかもしれませんが、それらは私のために機能します：

mysql: mysqldump --Host=%s -u %s --password=%s %s| gzip > %s
git  : git gc
       git bundle
files: tar --force-local -czf %s %s

ここでお勧めすることは、Wordpressインストールの周りのプロセスをWordpressから除外することです。特定のシステムで実行する必要があるため、通常はアプリケーション内でそれらを使用する必要はありません（たとえば、アプリケーションがダウンする可能性はありますが、これらを継続するにはneed動作するように）。

チームワークに対応

もう1つの素晴らしい利点は、サイトでチームワークが既に有効になっていることです。追加のベアリポジトリのおかげで、あまり間違ったことはできず、マスターブランチやライブブランチとは別にリモートブランチを同僚と共有することもできます。

5
hakre