Git / GitHub iyi bir WordPress dağıtım çözümü mı?

Şu anda WordPress'imi yerel olarak geliştiriyorum, kodumu Git ile GitHub'a ve sonra da sunucuma SSHing'e veriyorum ve kodumu güncellemek için bir "git çekme" yapıyorum. Bu, bir WordPress sitesine kod dağıtımı için iyi bir seçenek midir (bu durumda sunucuma kök düzey erişimim var.) Capistrano gibi şeyler biliyorum, ancak bu bir WordPress sitesine dağıtılmak için fazla mazur olur mu? Bu durumda Git / GitHub'tan en iyi şekilde nasıl yararlanabilirim?

Git'i bunun için kullanıyorum ve gerçekten iyi çalıştığını görüyorum. Birkaç öneri:

• Yüklemeler dizini (wp-content / uploads) dizini .gitignoredosyanızı ekleyin .
• Geliştirme sisteminizde bir web sunucusu ve veritabanı sunucusu çalıştırın; böylece değişiklikleri üretime almadan önce yerel olarak test edebilirsiniz.
• .gitignoreGeliştirme wordpress ayarlarınızın prodüksiyonlarınızın üzerine yazmasını engellemek için veritabanı bağlantı ayarlarınızı tutarlı bir şekilde saklayın ya da geliştirin ya da wp-config.php ekleyin .
• Wordpress'in yönetici arayüzünü kullanarak üretim sisteminizdeki eklentileri güncellemekten kaçının - en iyi şekilde, git kopyanız, ittirir / satın alır almaz güncellediğiniz eklentilerin üzerine yazacaktır, en kötüsü çakışırsınız. Geliştirme sisteminizdeki yönetici arayüzünü kullanarak güncellemelerinizi yapın, üretimde kararlı olun, itin ve ödeme yapın.

• post-receiveGüncellemeleri otomatik olarak web sunucunuz aracılığıyla wordpress yayınlamak için kullandığınız dizine teslim etmek için bir git kancası eklemeyi düşünün (örn. /var/www). Bu, web sunucunuzun belge köküne girme yolunu bulmak için git meta verilerinden kaçınarak yalnızca dosyaları kontrol etmenize olanak sağlar ve ayrıca alma sonrası kancaya izin değişiklikleri her zaman tutarlı kalması için izin değişiklikleri ekleyebileceğiniz anlamına gelir. Bir örnek aşağıda bulunur:

  #!/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'yu kurmanızı şiddetle tavsiye ederim - ilk defa biraz önden çalışma, ancak bundan sonra kolayca yeni kurulumlar için kullanabilirsiniz.

Başlıca avantajları:

• Masaüstünüzden konuşlandırmak. Kulağa çok hoş gelmeyebilir, ancak uzak sunucunuza sshing ve bir gitme işlemi hala götten ağrıyor.
• Gerekirse önceki sürüme kolay geri alma
• evreleme / üretim ortamlarına kurulum dağıtım gibi harika şeyler yapabilir.

Size işleri nasıl ayarladığımı göstermek için bir dizi capistrano senaryosu ekliyorum.

Capfile

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"

ve son olarak, örnek bir ortam dosyası (çok aşamalı bir taş kullanırsanız, o zaman ortamınızın her aşaması için bunlardan birine sahip olabilirsiniz, örneğin yerel, evreleme, üretim)

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

Bu dosyalar ince ayar olmadan çalışmayabilir ve bazı temel Capistrano bilgisine ihtiyacınız olacak, ancak umarım bazı insanlara yardımcı olacaktır.

Bu, beni Capistrano ve WordPress ile birlikte kullanmaya başladığım ilk dersti: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

Aslında bu konuda bir WordCamp sunumu yaptım. Kendimi tekrarlamak yerine, işte bunun bir ekranı ve işte tartıştığım şeye eşlik edecek çok basit bir dağıtım senaryosu .

Kısacası, repoyu barındırmak için GitHub'u kullanıyorum ve git ref'ye göre değişiklikleri dağıtmak için bir web kancası kullanıyorum. Bu, Vincent Driessen'in git branching modelini kullanmanıza izin verir ve sınırsız web başlığı, sunucu hazırlama, test sunucusu vb. Gibi işlemleri otomatik olarak başlatmanıza olanak tanır . Ayrı dev / prodüksiyon sürümlerini korurken wp-config.php'yi sürüm kontrolü altında tutmayı da kapsar (dosyaları yeniden adlandırarak ve işaretleyerek).

Bu sorunun biraz daha eski olduğunu biliyorum, ancak bunu burada bir cevap olarak görmediğim için, normalde tek site git tabanlı kurulumlar ve dağıtımlar için yaptığım şeyi paylaşmak istiyorum. aygıtlar, konumlar ve çok sayıda geliştiriciyle (tümü git için ortak olduğu için çalıştığı kendi yerel repolarına sahip olan).

Yürekten aşağıdaki kurulum önerebilirim:

• Web odaklı Git iş akışı (Joe Maller; Kasım 2008)

Ayrıca (başınızı etrafına sarmak için ikinci bir kaynağa ihtiyacınız varsa) ana hatlarıyla belirtilir:

• Git'i Dağıtım İçin Kullanma (Dan Barber; Nis 2011)

Temelde şu şekilde çalışır (en az üç depoyla):

1. web sitesini git altındaki canlı sunucuya koymak,
2. canlı ana bilgisayarda yeni bir çıplak git deposu oluşturun .
3. Ve daha sonra çıplak havuzdan yerel gelişiminize gidiniz.

İş bittiğinde, klonladığınız uzaktaki çıplak depoya doğru itiyorsunuz. Çıplak repo, canlı repo ile senkronize etmek için kancalara sahiptir (yukarıdaki kodlarda asal olarak adlandırılır ).

Depodaki Wordpress'e özgü ayarlar olarak aşağıdakilere sahibim .gitignore:

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

Gerisi dahil eklenti ve tema yapılandırması sürüm / yapılandırma kontrolü altında tutuyorum. Bu, canlı kullanmadan önce değişiklikleri kolayca izlememe ve kodu incelememe izin veriyor . Uzaktaki ağaçlara karşı kendi değişikliklerimle daha kolay birleşebilirim. Bu, özellikle Github'da bulunan Wordpress çekirdeğine karşı kullanışlıdır .

Bu benim Wordpress ihtiyaçlarımın çoğu için oldukça iyi çalışıyor. Çıplak repo, çelişen değişiklikleri zorlamanızı önler. Ayrıca, canlı siteyi güncellemeden önce ilk önce uzak bir kopya ile senkronize edilir. Bu, canlı siteyi güncellemek normalde oldukça hızlı olduğu anlamına gelir. Kancalar sayesinde, isterseniz Wordpress güncelleme kancalarını daha sonra çağırabilirsiniz.

Bunun Github kancalarıyla ne kadar geliştirilebileceğini denemediyseniz, ancak kodun Github yerine yerel sürüm kontrolü altında olduğundan normalde onlara ihtiyacım yok.

Böyle bir sistemi ilk kez kurmak için, uzaktaki ana makinenizdeki tüm araçları kullanıp kullanmadığınızı değerlendirmek için biraz zaman ayırmalısınız:

• SSH erişimi
• GYTE
• Dosyaları ve alt dizinleri içine koyabileceğiniz özel bir dizin (örneğin, çıplak git repo'nuz için)

İlk kez kurulum zamanı, iki saat dahil olmak üzere mümkün olmalıdır. tüm çevre ve ilk siz itin.

Ana makinenize bağlı olarak, .gitdizini web erişiminden de korumak isteyebilirsiniz . İşte .htaccessWordpress'in bir alt dizine yerleştirilmiş olmasına rağmen, çevrimiçi olarak yayınlanmayan repoda yer bırakan (kullanışlı) bazı örnek kod:

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]

Kısacası, genel dizinde olmayan her şey çevrimiçi değil. Genel dizinin içinde, örneğin .htaccesso zaman ihtiyacınız olan orada wordpress kod temeli olabilir :

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

Bu, halka doğrudan erişimi önler . .Htaccess -foo'nun bir bölümü burada ana hatlarıyla verilmiştir: .htaccess istekleri 403 yerine 404 döndürmelidir . Ortam değişkenleri için bunun ortamınızda çalışıp çalışmadığını test etmeniz gerekir. Ayrıca bunu sürüm kontrolü altına alıp almadığınıza karar vermeniz gerekir.

Barındırma üzerinde daha fazla denetime sahipseniz, burada daha fazla şey yapabilirsiniz (ve farklı / daha optimize edilmiş), yukarıdaki örnekler tipik paylaşılan barındırma ortamları için hedeflenmiştir (GIT’i sunar, bazı kullanıcılar kolayca kendi Peki, normalde barınağımcılardan böyle bir şey sağlamasını isterim çünkü onlara bunun için para ödediğim için özen göstermelerini tercih ederim.

Olumsuz tarafta, bunun diğer cevaplarda da belirtilen ortak sorunlardan bazıları var. Gurur duymadığım bir şey var, ancak işe yarar olan şey, geliştirme sunucusuna, veritabanı sunucusunun geliştirme kopyasını göstermesi için ana bilgisayar dosyasında bir değişiklik yapmasıdır. Böylece bir veritabanı yapılandırmasını koruyabilirsiniz. Gerçekten havalı değil esp. kimlik bilgileri nedeniyle.

Otomatik Yedeklemeler

Ancak normalde burada fazla umursamıyorum ama bunun yerine, art arda kendilerinin başka bir uzak konumda depolanan uzak sistemlerde günlük yedeklemeler çalışıyor. Bu kolay ve ucuzdur ve hem Wordpress kurulumunu hem de dosya yüklemelerini, veritabanını ve git deposunu geri yüklemenizi sağlar . Ayrıca yedekleme komutlarım için mükemmel olmayabilirim ama bunlar benim için işe yarıyor:

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

Burada önerdiğim şey, Wordpress kurulumunuzun etrafındaki işlemleri Wordpress'in dışında tutmanızdır. Onlar belirli bir sistem üzerinde çalıştırmak gerekir, bu nedenle normalde uygulama içinde bunları yok (inebilir örneğin uygulama ancak gerek bu çalışmaya devam için).

Takım Çalışması İçin Etkin

Bir başka güzel avantajı da sitenizin takım çalışması için zaten etkin olması. Ekstra çıplak repo sayesinde çok yanlış yapamazsınız ve hatta bir ana veya canlı şubeden uzaktaki şubeleri meslektaşlarınızla bile paylaşabilirsiniz.