Quy trình làm việc của WordPress và Git

Tôi biết câu hỏi này đã được hỏi hàng ngàn lần, nhưng tôi thực sự đang cố gắng tìm ra cách tận dụng Git tốt nhất khi làm việc với WordPress.

Tôi đã lướt web và đọc hàng tá bài báo, tất cả những điều đó dường như đề cập đến chủ đề này một cách ngắn gọn. Đây là một vài trong số những người đáng chú ý nhất mà tôi đã đọc gần đây.

- Phiên bản kiểm soát WordPress

- Quản lý triển khai chủ đề WordPress với Git

- Quản lý chủ đề WordPress tùy chỉnh của bạn bằng git thay vì FTP

Hiện tại, quy trình làm việc của tôi trông như thế này.

• Cài đặt WordPress cục bộ
• Phát triển chủ đề
• Xuất cơ sở dữ liệu WordPress từ máy chủ cục bộ
• Nhập cơ sở dữ liệu WordPress vào máy chủ từ xa
• Tải lên các tệp và chủ đề WordPress qua FTP
• Khách hàng thực hiện thay đổi
• Tải xuống các tệp và chủ đề WordPress qua FTP và xuất Cơ sở dữ liệu WordPress từ máy chủ từ xa
• Thay thế tệp cục bộ
• Thay đổi phát triển
• Tải lên lại qua FTP, xuất và nhập cơ sở dữ liệu lên máy chủ từ xa

Tôi nhận ra Git có thể hợp lý hóa quá trình này. Có vẻ như cách tốt nhất để làm điều này là có tệp .gitignore bỏ qua các thư mục nhất định không cần phải theo dõi, cũng như có cả tệp wp-config.php cục bộ và từ xa.

Nhưng làm thế nào để bạn xử lý các cơ sở dữ liệu? Khách hàng thường sẽ thực hiện thay đổi (bài viết / trang / plugin). Tôi vẫn cần xuất từ ​​cơ sở dữ liệu từ xa và nhập lại trên máy chủ cục bộ của mình chứ?

Ai đó có thể đề xuất quy trình làm việc tốt nhất cho tôi ở đây? Và dẫn tôi qua các bước.

Ngoài ra, tôi có thể muốn sử dụng Bitbucket làm repos riêng với chúng là miễn phí, không giống như GitHub.

Bất kỳ trợ giúp sẽ được đánh giá cao.

Cảm ơn trước!

Tôi là một trong những nhà phát triển của WP Migrate DB Pro và muốn trả lời câu hỏi của @ Ennui:

"Bạn có biết nếu db url thay thế tập lệnh mà nó chạy sẽ đưa vào chuỗi được nối tiếp tài khoản không?"

Có, nó xử lý dữ liệu nối tiếp. Trên thực tế, đó là lý do chính khiến tôi phát triển phiên bản miễn phí của plugin vào năm 2009. :)

Thật không may, tôi chỉ có danh tiếng là 41, vì vậy không thể trả lời bình luận của @ Ennui. Xin lỗi vì điều đó.

Tôi không giới hạn việc bỏ phiếu để đóng cái này là "không mang tính xây dựng" vì nó dường như là thứ sẽ thu hút tranh luận và ý kiến ​​hơn là câu trả lời. Nhưng...

Đó không phải là dòng công việc của tôi trông như thế nào, và nó làm cho cách tiếp cận (và câu trả lời) của tôi khác với hầu hết các câu trả lời còn lại cho đến nay.

1. Cài đặt WordPress cục bộ
   1. Điều này được nhân bản từ một repo trần địa phương có chứa bản phát hành ổn định mới nhất.
   2. Tôi cũng giữ một bản sao cục bộ của bản phát hành mới nhất của một vài plugin mà tôi gần như luôn cài đặt.
2. Xây dựng chủ đề và mọi plugin cần thiết
3. Tải lên máy chủ dàn công cộng
   1. Máy khách được cấp quyền truy cập nhưng không thể thay đổi mã và thông báo rằng các chỉnh sửa cơ sở dữ liệu sẽ không được chuyển đến trang sản xuất.
   2. Điều này có nghĩa là không có lý do để tải mã trở lại máy chủ phát triển.
   3. Và không có lý do để đồng bộ lại cơ sở dữ liệu cục bộ
4. Thay đổi trang web địa phương dựa trên nhân viên của chúng tôi và phản hồi của khách hàng.
5. Tải lên thay đổi
6. Lặp lại khi cần thiết (nhưng với sức đề kháng tăng :))
7. Nếu chúng tôi đang cung cấp nội dung, không phải lúc nào cũng như vậy, chúng tôi (không phải khách hàng) sẽ dọn dẹp cơ sở dữ liệu trên máy chủ dàn dựng và tải lên nội dung.
8. Triển khai bằng cách tải mã địa phương lên trang sản xuất.
9. Nếu chúng tôi đã tạo nội dung, nội dung được xuất từ ​​trang dàn dựng thông qua công cụ xuất vanilla và được nhập vào trang sản xuất.
   1. Đây là lần duy nhất tôi phải di chuyển cơ sở dữ liệu và nó được thực hiện với các công cụ khá chuẩn. Tôi sẽ sử dụng URL Cập nhật Velvet Blues để dọn dẹp cơ sở dữ liệu nếu cần.
10. Gỡ lỗi
11. Kết thúc

Về cơ bản, tôi giữ khách hàng tránh xa công cụ của mình càng nhiều càng tốt cho đến khi chúng tôi bàn giao trang web.

Mã di chuyển một chiều - từ địa phương sang dàn dựng hoặc sản xuất. Nó không bao giờ di chuyển theo cách khác. Điều đó giúp loại bỏ một số bước của bạn và giúp tôi yên tâm. Tôi không muốn bị đổ lỗi cho việc sửa đổi mã của khách hàng và tôi không muốn nhập một số tệp bị hack, đây là một khả năng khác không.

Và cơ sở dữ liệu chỉ di chuyển một lần, nếu có, điều đó làm giảm đáng kể vấn đề. Vì vậy, tôi đoán rằng tôi quản lý vấn đề "di chuyển cơ sở dữ liệu" bằng cách giảm hoặc loại bỏ nhu cầu di chuyển cơ sở dữ liệu. Nó cũng làm giảm các vấn đề tham nhũng cơ sở dữ liệu có thể phát sinh và giảm cơ hội nhập hack.

Đúng, tôi phải cấu hình trang sản xuất-- permalinks, menu, v.v .-- nhưng điều đó buộc tôi phải làm việc trên trang sản xuất nên tôi coi đó là một loại gỡ lỗi. Nó giúp tôi xác nhận rằng mọi thứ hoạt động trên trang web sản xuất theo cách họ nên.

https://github.com/nathanielks/Wordpress-Capistrano- Triển khai

Tôi đã không thử điều này (chưa), nhưng nó tuyên bố sẽ triển khai mọi thứ - bao gồm DB.

Ngoài ra còn có một hướng dẫn đi kèm với nó: Hướng dẫn phần 1 | phần 2

Hãy nhìn vào ngăn xếp bedrock . Nó sử dụng trình soạn thảo để quản lý phiên bản của Wordpress và các plugin của bên thứ ba, đồng thời bao gồm capistrano để triển khai và vagrant / ansible để thiết lập máy chủ bao gồm cả máy chủ ảo cục bộ để phát triển.

Gần đây tôi đã thực hiện rất nhiều thử nghiệm liên quan đến vấn đề này và đây là quy trình công việc tôi sử dụng, thực hiện khá nhiều thứ bạn đang yêu cầu:

• Tôi sử dụng wp-cli để quản lý lõi wordpress và cập nhật wordpress.
• Tôi sử dụng trình soạn thảo cùng với http://wpackagist.org để quản lý các phụ thuộc plugin và chủ đề.
• Tôi sử dụng git và đặt các tập tin wp lõi trong .gitignore. Vì vậy, chủ yếu là wp-config.php và các tệp chủ đề con nằm trong git.

Tôi không quen thuộc với các công cụ di chuyển db nhưng sẽ là một bổ sung tuyệt vời cho quy trình công việc này.

Dưới đây là chi tiết đầy đủ về quy trình làm việc http://geekpad.ca/blog/post/maintainble-portable-wordpress-USE-composer-wp-cli

Về cơ sở dữ liệu "nhân bản", tôi sử dụng WP Migrate DB Pro: http://delicybrains.com/wp-migrate-db-pro/

Đó là một dịch vụ trả phí, nhưng không tốn nhiều chi phí và dễ dàng cho phép bạn kéo hoặc đẩy cơ sở dữ liệu của mình từ nhà phát triển đến máy chủ trực tiếp và ngược lại. Nó thay đổi các URL và mọi thứ khác cần thay đổi trên đường đi.