Git / GitHub는 훌륭한 WordPress 배포 솔루션입니까?

현재 WordPress를 로컬로 개발하고 Git을 사용하여 코드를 GitHub에 커밋 한 다음 서버에 SSH로 연결하고 "git pull"을 수행하여 코드를 업데이트하고 있습니다. 이것은 WordPress 사이트에 코드를 배포하기위한 좋은 옵션입니까 (이 경우 분명히 서버에 대한 루트 수준 액세스 권한이 있습니다.) Capistrano와 같은 것을 알고 있지만 WordPress 사이트에 배포하기에는 너무 무리가 있습니까? 이 경우 Git / GitHub를 최대한 활용하려면 어떻게해야합니까?

나는 이것을 위해 git을 사용하고 그것이 실제로 잘 작동한다는 것을 알았다. 몇 가지 제안 :

• 업로드 디렉토리 (wp-content / uploads) 디렉토리를 .gitignore파일에 추가하십시오.
• 개발 시스템에서 웹 서버 및 데이터베이스 서버를 실행하여 변경 사항을 프로덕션으로 푸시하기 전에 로컬로 테스트 할 수 있습니다.
• 개발 및 .gitignoreWordPress 설정이 프로덕션 설정을 덮어 쓰지 않도록 데이터베이스 연결 설정을 dev와 prod간에 일관되게 유지하거나 wp-config.php를 파일에 추가 하십시오.
• Wordpress의 관리 인터페이스를 사용하여 프로덕션 시스템에서 플러그인을 업데이트하지 마십시오. 기껏해야 git copy는 푸시 / 체크 아웃하자마자 업데이트하는 플러그인을 덮어 씁니다. 최악의 경우 충돌이 발생합니다. 개발 시스템의 관리 인터페이스를 사용하여 업데이트를 수행하고 프로덕션 환경에서 커밋, 푸시 및 체크 아웃하십시오.

• post-receive웹 서버를 통해 워드 프레스를 게시하는 데 사용하는 디렉토리에 업데이트를 자동으로 체크 아웃하려면 git hook을 추가 하십시오 (예 :) /var/www. 이를 통해 파일 자체 만 체크 아웃 할 수 있으며 git 메타 데이터가 웹 서버의 문서 루트에 들어가는 것을 피할 수 있으며 수신 후 후크에 권한 변경 사항을 추가하여 매번 권한이 일관되게 유지 될 수 있습니다. 예는 다음과 같습니다.

  #!/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

Capistrano를 설정하는 것이 좋습니다. 처음에는 약간의 선행 작업이지만 그 후에는 새로운 설정에 쉽게 사용할 수 있습니다.

주요 장점은

• 데스크톱에서 배포 할 수 있습니다. 많이 들리지는 않지만 원격 서버에 ssh-ing하고 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 git@github.com: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"

마지막으로 샘플 환경 파일 (다단계 젬을 사용하는 경우 로컬, 스테이징, 프로덕션 등 환경의 각 단계마다 이들 중 하나를 가질 수 있음)

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-deploying-wordpress-with-capistrano-2082/

실제로이 주제에 대해 WordCamp 프레젠테이션을했습니다. 나 자신을 반복하지 말고 여기에 스크린 캐스트가 있으며 여기에서 논의한 내용과 함께 제공 되는 매우 간단한 배포 스크립트 가 있습니다.

즉, GitHub를 사용하여 리포지를 호스팅하고 웹 후크를 사용하여 git ref를 기반으로 변경 사항을 배포합니다. 이를 통해 Vincent Driessen의 git 브랜칭 모델 을 사용할 수 있으며 자동화 된 배포를 통해 무제한 웹 헤드, 스테이징 서버, 테스트 서버 등을 가질 수 있습니다. 또한 별도의 개발 / 제작 버전을 유지하면서 (파일 이름 변경 및 심볼릭 링크를 통해) wp-config.php를 버전 제어 상태로 유지하는 방법을 다룹니다.

나는이 질문이 조금 오래되었다는 것을 알고 있지만 여기에 대한 대답으로 보지 못 했으므로 단일 사이트 git 기반 설정 및 배포에서 일반적으로하는 일을 공유하고 싶습니다. 장치, 위치 및 여러 개발자 (모두 자체 로컬 리포지토리가 있으며 git에 공통적으로 작동 함).

다음 설정을 진심으로 제안 할 수 있습니다.

• 웹 중심의 Git 워크 플로우 (Joe Maller, 2008 년 11 월)

또한 머리를 감싸기 위해 두 번째 리소스가 필요한 경우에 설명되어 있습니다.

• 배포를 위해 Git 사용 (Dan Barber, 2011 년 4 월)

기본적으로 다음과 같은 방법으로 작동합니다 (최소한 세 번의 repos 사용).

1. 웹 사이트를 git 아래의 라이브 호스트에 배치
2. 라이브 호스트에 새로운 베어 git 저장소 를 만듭니다 .
3. 그런 다음 기본 저장소에서 로컬 개발 git repo (s)로 분기합니다.

작업이 완료되면 복제 한 원격 베어 리포지토리를 누르십시오. 베어 리포지토리는 라이브 리포지토리와 동기화 할 후크가 있습니다 (위의 코드는 prime ).

repo의 Wordpress 특정 설정으로 나는 이것을 가지고 있습니다 .gitignore:

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

나머지는 포함합니다. 버전 / 구성 제어하에 유지되는 플러그인 및 테마 구성. 이를 통해 변경 사항을 추적하고 코드 를 실시간으로 사용 하기 전에 검토 할 수 있습니다. 또한 내 자신의 변경 사항으로 원격 트리에보다 쉽게 ​​병합 할 수 있습니다. 이는 Github에서 사용할 수 있는 Wordpress 코어 에 특히 유용합니다 .

이것은 대부분의 Wordpress 요구에 아주 잘 작동합니다. Bare Repo는 충돌하는 변경 사항을 적용하지 못하게합니다. 또한 라이브 사이트를 업데이트하기 전에 먼저 원격 사본과 동기화됩니다. 즉, 라이브 사이트 업데이트는 일반적으로 매우 빠릅니다. 후크 때문에 원하는 경우 나중에 Wordpress 업데이트 후크를 호출 할 수도 있습니다.

Github 후크로 얼마나 향상시킬 수 있는지 실험하지 않았지만 코드가 Github가 아닌 로컬 버전 제어하에 있기 때문에 일반적으로 필요하지 않습니다.

이러한 시스템을 처음으로 설정하려면 원격 호스트에서 사용 가능한 모든 도구가 있는지 평가하는 데 시간이 걸립니다.

• SSH 액세스
• GIT
• 파일 및 하위 디렉토리를 넣을 수있는 개인 디렉토리 (예 : 베어 git 저장소)

처음 설정 시간은 다음을 포함하여 1 시간 내에 가능해야합니다. 전체 환경과 먼저 푸시를 게시합니다.

호스트에 따라 .git웹 액세스로부터 디렉토리 를 보호 할 수도 있습니다. 다음은 .htaccessWordpress가 하위 디렉토리 안에 배치되어 저장소의 공간이 온라인으로 게시되지 않는 유용한 사이트입니다 (유용함).

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]

간단히 말해서, 공용 디렉토리에없는 모든 것이 온라인이 아닙니다. 예를 들어 공개 디렉토리 안에 워드 프레스 코드베이스가 .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를 제공하는 일부 사용자는 다음과 같이 쉽게 설치할 수 있다고 말합니다) 글쎄, 나는 일반적으로 내가 주최하는 사람들이 내가 돌보는 것을 선호하는지에 따라 호스트에게 그러한 것을 제공하도록 요청합니다.

부정적인 측면에서, 이것은 다른 답변들에 요약 된 일반적인 문제들 중 일부를 가지고 있습니다. 내가 자랑스럽지 않지만 작동하는 것은 데이터베이스 서버가 개발 사본을 가리 키도록 개발 호스트에 호스트 파일을 변경하는 것입니다. 따라서 하나의 데이터베이스 구성을 유지할 수 있습니다. 정말 멋진 esp. 자격 증명으로 인해

자동 백업

그러나 나는 일반적으로 여기에별로 신경 쓰지 않지만 대신 원격 시스템에서 매일 백업을 실행하여 점차적으로 다른 원격 위치에 저장됩니다. 쉽고 저렴하며 Wordpress 설치와 파일 업로드, 데이터베이스 및 git repo를 모두 복원 할 수 있습니다 . 또한 내 백업 명령의 경우 완벽하게 잘 보이지는 않지만 저에게 효과적입니다.

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 설치 프로세스를 유지하는 것입니다. 그들은 특정 시스템에서 실행해야합니다, 그래서 당신은 일반적으로 응용 프로그램 내에서 그들이없는 (아래로 갈 수 있습니다 예를 들어, 응용 프로그램하지만 당신은 필요로 이러한 작업을 계속하도록).

팀워크에 사용

또 다른 좋은 이점은 사이트가 이미 팀워크를 위해 활성화되어 있다는 것입니다. 추가 베어 저장소 덕분에 많은 잘못을 저지를 수 없으며 마스터 또는 라이브 브랜치와 다른 원격 브랜치를 동료와 공유 할 수도 있습니다.