Git / GitHub có phải là một giải pháp triển khai WordPress tốt không?

Tôi hiện đang phát triển WordPress cục bộ, cam kết mã của mình với GitHub bằng Git và sau đó SSH vào máy chủ của tôi và thực hiện "git pull" để cập nhật mã của tôi. Đây có phải là một lựa chọn tốt để triển khai mã trên trang web WordPress (tôi rõ ràng có quyền truy cập cấp độ gốc vào máy chủ của mình trong trường hợp này.) Tôi biết những thứ như Capistrano, nhưng điều đó có quá mức cần thiết để triển khai lên trang web WordPress không? Làm cách nào tôi có thể tận dụng tối đa Git / GitHub trong trường hợp này?

Tôi sử dụng git cho việc này và thấy nó hoạt động thực sự tốt. Một vài gợi ý:

• Thêm thư mục tải lên (wp-content / uploads) vào .gitignoretệp của bạn .
• Chạy một máy chủ web và máy chủ cơ sở dữ liệu trên hệ thống phát triển của bạn để bạn có thể kiểm tra các thay đổi cục bộ trước khi đẩy chúng vào sản xuất.
• Giữ các cài đặt kết nối cơ sở dữ liệu của bạn nhất quán giữa dev và prod, hoặc thêm wp-config.php vào .gitignoretệp của bạn để ngăn cài đặt wordpress phát triển của bạn ghi đè lên các sản phẩm của bạn.
• Tránh cập nhật các plugin trên hệ thống sản xuất của bạn bằng giao diện quản trị của Wordpress - vì tốt nhất, bản sao git của bạn sẽ ghi đè bất kỳ plugin nào bạn cập nhật ngay khi bạn đẩy / thanh toán, tệ nhất là bạn sẽ gặp xung đột. Thực hiện cập nhật của bạn bằng giao diện quản trị viên trên hệ thống phát triển của bạn, cam kết, đẩy và kiểm tra trong sản xuất.

• Xem xét thêm một git post-receivehook để tự động kiểm tra các cập nhật của bạn vào thư mục bạn sử dụng để xuất bản wordpress qua máy chủ web của bạn (ví dụ /var/www). Điều này cho phép bạn chỉ tự kiểm tra các tệp, tránh mọi siêu dữ liệu git tìm đường vào gốc tài liệu của máy chủ web của bạn và cũng có nghĩa là bạn có thể thêm bất kỳ thay đổi quyền nào vào móc nhận sau để quyền của bạn luôn nhất quán. Một ví dụ được bao gồm dưới đây:

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

Tôi thực sự khuyên bạn nên thiết lập Capistrano - lần đầu tiên có một chút công việc trả trước, nhưng sau đó bạn có thể dễ dàng sử dụng nó cho các thiết lập mới.

Những lợi thế chính là

• có thể triển khai từ máy tính để bàn của bạn. Nghe có vẻ không nhiều, nhưng ssh-ing vào máy chủ từ xa của bạn, và thực hiện thao tác kéo git vẫn là một nỗi đau ở mông.
• dễ dàng quay trở lại phiên bản trước nếu bạn cần
• có thể làm những việc hay ho như triển khai thiết lập cho môi trường dàn dựng / sản xuất.

Tôi đang thêm một tập các tập lệnh capistrano để cho bạn thấy cách tôi thiết lập mọi thứ.

Capfile

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

triển khai.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"

và cuối cùng, một tệp môi trường mẫu (nếu bạn sử dụng đá quý nhiều tầng, thì bạn có thể có một trong số chúng cho từng giai đoạn của môi trường của bạn, ví dụ: cục bộ, dàn dựng, sản xuất)

cấu hình / 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

Các tệp này có thể không hoạt động nếu không tinh chỉnh và bạn sẽ cần một số kiến ​​thức cơ bản về Capistrano, nhưng hy vọng sẽ giúp được một số người.

Đây là hướng dẫn đầu tiên tôi sử dụng giúp tôi sử dụng Capistrano và WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

Tôi thực sự đã trình bày WordCamp về chủ đề này. Thay vì lặp lại bản thân mình, đây là một đoạn trích của nó và đây là một kịch bản triển khai rất đơn giản để đi kèm với những gì tôi đã thảo luận.

Nói tóm lại, tôi sử dụng GitHub để lưu trữ repo và sử dụng webhook để triển khai các thay đổi dựa trên git ref. Điều này cho phép bạn sử dụng mô hình phân nhánh git của Vincent Driessen và mở ra cho bạn để có các webhead không giới hạn, máy chủ dàn dựng, máy chủ thử nghiệm, v.v., tất cả đều có triển khai tự động. Tôi cũng bao gồm việc giữ wp-config.php dưới sự kiểm soát phiên bản trong khi duy trì các phiên bản dev / sản xuất riêng biệt (bằng cách đổi tên các tệp và liên kết tượng trưng).

Tôi biết câu hỏi này hơi cũ một chút tuy nhiên tôi chưa xem đây là câu trả lời ở đây, tôi muốn chia sẻ những gì tôi thường làm cho các thiết lập và triển khai dựa trên git một trang web và nó hoạt động rất tốt, cũng như làm việc từ nhiều các thiết bị, địa điểm và với nhiều nhà phát triển (tất cả đều có repos cục bộ riêng mà họ hoạt động vì nó là phổ biến cho git).

Tôi chân thành có thể đề nghị thiết lập sau:

• Một quy trình làm việc Git tập trung vào web (bởi Joe Maller; tháng 11 năm 2008)

Nó cũng được phác thảo trong (nếu bạn cần một tài nguyên thứ hai để quấn đầu xung quanh nó):

• Sử dụng Git để triển khai (bởi Dan Barber; tháng 4 năm 2011)

Về cơ bản, nó hoạt động (với ít nhất ba repos) bằng cách:

1. đưa trang web lên máy chủ trực tiếp dưới git,
2. tạo một kho git trần mới trên máy chủ trực tiếp.
3. Và sau đó rẽ nhánh từ kho lưu trữ trần để phát triển địa phương git repo (s).

Khi công việc hoàn thành, bạn chống lại repo từ xa mà bạn đã nhân bản. Repo trần có móc để đồng bộ với repo trực tiếp (trong các mã ở trên được gọi là số nguyên tố ).

Như cài đặt cụ thể của Wordpress trong repo, tôi có cái này .gitignore:

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

Phần còn lại bao gồm. Cấu hình plugin và chủ đề tôi giữ dưới sự kiểm soát phiên bản / cấu hình. Điều này cho phép tôi dễ dàng theo dõi các thay đổi và xem lại mã trước khi sử dụng trực tiếp. Tôi cũng có thể dễ dàng hợp nhất hơn với các cây từ xa với những thay đổi của riêng tôi. Điều đó đặc biệt hữu ích đối với lõi Wordpress có sẵn trên Github .

Điều này hoạt động khá tốt cho hầu hết các nhu cầu Wordpress của tôi. Repo trần ngăn bạn đẩy các thay đổi xung đột. Nó cũng đồng bộ hóa với một bản sao từ xa trước khi cập nhật trang web trực tiếp. Điều đó có nghĩa là, cập nhật trang web trực tiếp thường khá nhanh. Do các hook bạn thậm chí có thể gọi hook cập nhật Wordpress sau đó nếu bạn thích.

Nếu chưa thử nghiệm điều này có thể cải thiện được bao nhiêu với các móc Github, nhưng tôi thường không cần chúng vì mã nằm dưới sự kiểm soát phiên bản cục bộ, không phải Github.

Để thiết lập một hệ thống như vậy lần đầu tiên, bạn nên dành chút thời gian để đánh giá xem bạn đã có tất cả các công cụ có sẵn trên máy chủ từ xa chưa:

• Truy cập SSH
• GIT
• Một thư mục riêng bạn có thể đặt các tệp và thư mục con vào (ví dụ: repo git trần của bạn)

Thời gian thiết lập lần đầu tiên nên có thể trong vòng một hai giờ. toàn bộ môi trường và lần đầu tiên bạn xuất bản đẩy.

Tùy thuộc vào máy chủ của bạn, bạn cũng có thể muốn bảo vệ .gitthư mục khỏi truy cập web. Dưới đây là một số .htaccessmã ví dụ thậm chí có Wordpress được đặt trong thư mục con, để lại không gian trong repo không được công bố trực tuyến (hữu ích):

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]

Nói tóm lại, mọi thứ không nằm trong thư mục công cộng đều không trực tuyến. Trong thư mục công cộng có thể là cơ sở mã wordpress, ví dụ, .htaccessở đó bạn cần:

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

Điều này ngăn chặn truy cập trực tiếp đến công chúng . Một phần của .htaccess này -foo bạn có thể tìm thấy được phác thảo ở đây: Yêu cầu .htaccess sẽ trả về 404 thay vì 403 . Đối với các biến môi trường, bạn cần kiểm tra xem nó có hoạt động trong môi trường của bạn không. Ngoài ra, bạn cần phải quyết định nếu bạn đặt nó dưới sự kiểm soát phiên bản hay không.

Nếu bạn có nhiều quyền kiểm soát hơn đối với việc lưu trữ, bạn có thể thực hiện nhiều nội dung hơn tại đây (và khác biệt / tối ưu hóa hơn), các ví dụ trên được nhắm mục tiêu cho các môi trường lưu trữ chia sẻ điển hình (cung cấp GIT, một số người dùng cho biết bạn có thể dễ dàng cài đặt nó như tốt, tôi thường yêu cầu chủ nhà của tôi cung cấp như vậy bởi vì tôi thích nếu họ quan tâm đó là những gì tôi trả cho họ).

Về mặt tiêu cực, điều này có một số vấn đề phổ biến cũng được nêu ra trong các câu trả lời khác. Một điều tôi không tự hào nhưng điều làm việc là cung cấp cho máy chủ phát triển thay đổi tệp lưu trữ của nó để máy chủ cơ sở dữ liệu trỏ đến bản sao phát triển. Vì vậy, bạn có thể giữ một cấu hình cơ sở dữ liệu. Không thực sự mát mẻ. bởi vì các thông tin

Tự động sao lưu

Tuy nhiên, tôi thường không quan tâm nhiều ở đây mà thay vào đó, có các bản sao lưu hàng ngày chạy trên các hệ thống từ xa đang dần dần được lưu trữ ở một vị trí từ xa khác. Điều đó dễ dàng và rẻ tiền và cho phép bạn khôi phục cả cài đặt Wordpress cũng như tải lên tệp, cơ sở dữ liệu và git repo. Ngoài ra đối với các lệnh sao lưu của tôi, tôi có thể không hoàn toàn ổn, nhưng những lệnh này hoạt động với tôi:

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

Điều tôi đề nghị ở đây là bạn giữ các quy trình xung quanh bản cài đặt Wordpress của bạn ra khỏi Wordpress. Chúng cần phải chạy trên một hệ thống cụ thể, vì vậy bạn thường không có chúng bên trong ứng dụng (ví dụ: ứng dụng có thể bị hỏng nhưng bạn cần phải tiếp tục hoạt động).

Kích hoạt cho tinh thần đồng đội

Một lợi ích tốt đẹp khác là trang web của bạn đã được kích hoạt để làm việc theo nhóm. Nhờ có repo trần bổ sung, bạn không thể làm gì sai và thậm chí bạn có thể chia sẻ các chi nhánh từ xa ngoài một chủ hoặc chi nhánh trực tiếp với các đồng nghiệp của mình.