Nhiều nhà phát triển / biên tập viên đang làm việc trên một trang web đang tiến hành


28

Lý lịch

Tôi đang ở gần giai đoạn cuối cùng của việc xây dựng trang web WordPress khá lớn đầu tiên của mình và bây giờ tôi gặp phải một số ma sát. Đối với hầu hết các phần, trang web được phát triển trên máy cục bộ của tôi và tôi sẽ đẩy các thay đổi lên máy chủ dàn dựng để xem xét ( xem câu hỏi này để có thêm thông tin ). Giải pháp tôi đã kết thúc khá hiệu quả khi chỉ là tôi chỉnh sửa nội dung, nhưng bây giờ một số người khác đang chỉnh sửa nội dung trong khi tôi vẫn có các tính năng để thêm. Ý tưởng là: chúng tôi có thể hoàn thành công việc nhanh hơn nếu các tính năng và nội dung kết hợp với nhau trong buổi hòa nhạc ... nhưng bây giờ tôi không chắc lắm.

Hiện tại có cơ sở dữ liệu khác nhau trên cơ sở dữ liệu trên máy chủ dàn so với trên máy cục bộ của tôi. Bản thân nó cũng ổn, vì tôi không cần bản sao cơ thể cuối cùng trên máy cục bộ của mình, nhưng tôi cần phát triển thêm, điều này sẽ ảnh hưởng đến cơ sở dữ liệu (cài đặt / ghi thêm một vài plugin cần bảng của riêng chúng).

Câu hỏi của tôi là:

Có cách nào dễ dàng để tự động hóa việc hợp nhất cơ sở dữ liệu để nhiều người có thể làm việc trên bản cài đặt WordPress không? Tất nhiên, tôi có thể chỉ xuất các bảng mà tôi biết đã thay đổi trên máy cục bộ của mình và đẩy chúng đến máy chủ dàn, nhưng có thể cũng có những thứ trên máy chủ dàn mà tôi muốn đưa xuống. Tôi có thể lấy đầu ra SQL của cả hai DB và khác chúng ... nhưng điều đó có vẻ tẻ nhạt và hackish. Tôi tự hỏi nếu đây là một vấn đề mà người khác đã giải quyết; nếu có một cách được cộng đồng chấp nhận để xử lý loại việc này.

Cảm ơn!


Bỏ phiếu để đóng hoặc chuyển đến một trang web khác (Jan: bạn có suy nghĩ gì về một trang tốt không? Superuser có thể). Đây không phải là cụ thể của WordPress, vì bạn gặp phải các vấn đề tương tự trên Drupal, Joomla hoặc bất kỳ trang web nào do PHP + MySQL điều khiển, cho vấn đề đó.
John P Bloch

Điều đó đã được nói, đề nghị của tôi là bạn sử dụng một máy chủ dàn từ xa thay vì một máy chủ cục bộ.
John P Bloch

@ John P Bloch: Với Drupal, một cái gì đó như Drush sẽ giúp ích rất nhiều trong tình huống này. Cá nhân tôi đã quen với Django, nơi những loại vấn đề này được giảm thiểu bằng đồ đạc. Ngoài ra, tôi hiện có hai máy chủ dàn: một cục bộ và một điều khiển từ xa. Có điều là tôi thực hiện công việc của mình trên máy từ xa, nhưng cần đẩy nó lên máy chủ để người khác có thể nhìn thấy. Máy chủ cuối cùng là thứ sẽ được thiết lập khi chúng ta có mọi thứ cùng nhau.
Gavin Anderegg

2
@ John P Bloch - Tôi nghĩ có nhiều lý do tại sao điều này có ý nghĩa như một câu hỏi hay ở đây. Tôi không có thời gian để trả lời nó vào lúc này nhưng hy vọng những người khác làm được.
MikeSchinkel

1
@Gavin: Xin lỗi, tôi đã hiểu sai câu hỏi của bạn. Có, tôi tin rằng sẽ ghi đè lên mọi thứ trên máy chủ sản xuất. : /
Zack

Câu trả lời:


16

Tôi đã hỏi câu hỏi này hơn một năm trước và trong thời gian đó chúng tôi đã thêm nhiều người vào nhóm của mình và phát triển số lượng trang web lớn hơn nhiều trong WordPress. Tôi muốn đi qua quy trình của chúng tôi trong trường hợp nó có thể giúp đỡ bất cứ ai khác.

Mọi thứ trong Git

Đây là điều tôi đang làm ngay cả khi tôi đặt câu hỏi, nhưng thật tốt khi gọi điểm này. Sử dụng Git không chỉ giúp chúng tôi làm việc hiệu quả hơn mà còn tiết kiệm được những cú lừa tập thể của chúng tôi nhiều lần.

Bạn đã bao giờ cần phải thực hiện cải tạo cấu trúc lớn cho một trang web, có được sự chấp thuận cho những cải tạo đó từ khách hàng và tất cả các bản cập nhật nhỏ cho phiên bản không được cải tạo? Chúng tôi có, và Git cho chúng tôi làm điều đó. Mô tả thiết lập này sẽ hơi dài dòng, nhưng điều cơ bản là chúng tôi đã tạo một nhánh mới, kéo nhánh đó lên máy chủ và gắn một tên miền phụ vào nhánh đó.

Chúng tôi cũng đã được cứu bởi Git. Tất nhiên nó cho phép chúng tôi khôi phục các thay đổi, điều này thật tuyệt, nhưng nó cũng cho phép chúng tôi đưa các phiên bản cũ của các tệp trở lại. Điều này có nghĩa là nếu một khách hàng hỏi: "Hãy nhớ phần này của trang web hoạt động như thế nào khoảng một năm trước? Chúng ta có thể mang nó trở lại không?", Câu trả lời là có - ngay cả khi người được hỏi không tham gia dự án đó một năm trước đây

Bên cạnh những điểm này, điều đó cũng có nghĩa là chúng tôi không bao giờ bị mắc kẹt nếu không có các tệp chúng tôi cần. Chúng tôi luôn có thể kéo xuống phiên bản mới nhất của trang web từ bất kỳ máy nào và bắt đầu thực hiện thay đổi.

Sử dụng Git để triển khai

Chúng tôi thực hiện lưu trữ WordPress trên Media Temple và chúng tôi thực sự thích chúng. Họ không phải là nhà cung cấp rẻ nhất, nhưng dịch vụ của họ rất tuyệt vời và máy chủ của họ thực sự được thiết lập tốt. Cũng cung cấp Git theo mặc định. Điều này có nghĩa là chúng ta có thể thiết lập máy chủ thành kho lưu trữ Git và kéo các thay đổi theo cách đó thay vì sử dụng SFTP. Điều đó cũng có nghĩa là thực hiện công việc trên máy chủ không có nguy cơ bị ghi đè (vì những thay đổi đó chỉ có thể được hợp nhất và đẩy lùi).

Vì chúng tôi sử dụng BitBucket làm máy chủ Git của chúng tôi, nên cần thêm một chút công việc ở đây. Trước hết, chúng tôi sử dụng các tệp .ssh / config để chúng tôi có thể nhập những thứ như ssh sitenameđăng nhập vào máy chủ của mình (chúng tôi cũng sử dụng SSH không mật khẩu , điều này giúp việc này trở nên siêu dễ dàng). Chúng tôi cũng đảm bảo luôn sử dụng cụm mật khẩu ssh (Mac OS X làm cho việc này trở nên rất dễ dàng bằng cách cho phép bạn lưu trữ cụm mật khẩu của mình trong Keychain.app ). Cuối cùng, chúng tôi thêm một dòng ForwardAgent vào mục .ssh / config trên các máy chủ mà chúng tôi muốn lấy từ đó. Điều này có nghĩa là chúng tôi chỉ cần khóa công khai SSH của mỗi người trong BitBucket chứ không phải khóa chung của mỗi máy chủ. Chúng tôi cũng đảm bảo giữ .gitthư mục một thư mục phía trên thư mục HTML công khai.

Cơ sở dữ liệu tự động

Khi máy chủ ở chế độ sản xuất, chúng tôi đảm bảo tự động sao lưu cơ sở dữ liệu của chúng tôi, chỉ trong trường hợp .

Mọi người đều có wp-config của riêng mình

Bởi vì tất cả chúng ta đều có tên người dùng và mật khẩu cơ sở dữ liệu cục bộ của riêng mình và vì chúng ta có thể sử dụng các tên và cơ chế phục vụ khác nhau, mỗi chúng ta đều giữ tệp wp-config của riêng mình. Mỗi trong số này được lưu trữ trong Git với một tên như wp-config-gavin.phpvà khi chúng tôi muốn sử dụng cấu hình đó, chúng tôi liên kết nó với wp-config.php(được Git bỏ qua bằng cách sử dụng .gitignore ).

Điều này cũng cho phép chúng ta ghi đè siteurltùy chọn trong wp_optionsbảng cơ sở dữ liệu như sau:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Điều này ngăn WordPress xem xét cơ sở dữ liệu cho vị trí máy chủ và có nghĩa là không có sự khác biệt kỳ lạ về vị trí giữa cài đặt cục bộ và máy chủ.

Một lưu ý cuối cùng về các tệp wp-config.php: đảm bảo lưu trữ chúng phía trên thư mục HTML công khai và làm cho các quyền chỉ được đọc cho người dùng web . Điều này tạo ra một sự khác biệt rất lớn trong việc bảo mật WordPress.

Vấn đề cơ sở dữ liệu

Cuối cùng, thịt của vấn đề.

Điều tôi phải chấp nhận là, khi sử dụng WordPress, không có cách nào tốt để "hợp nhất" các thay đổi cơ sở dữ liệu. Thay vào đó, chúng tôi cần phát triển các quy tắc ứng xử để giải quyết điều này. Các quy tắc khá đơn giản, và đã phục vụ chúng tôi tốt cho đến nay.

Trong quá trình phát triển, có một người duy nhất "sở hữu" trang web. Người đó thường thực hiện cài đặt (kết hợp gói lưu trữ với nhau, bắt đầu dự án Basecamp, cắt thiết kế, đại loại như vậy). Khi người đó đến điểm hợp lý, kết xuất cơ sở dữ liệu để cài đặt WordPress và đưa nó vào Git. Từ thời điểm đó trở đi, mọi người thực hiện phát triển đều sử dụng kết xuất cơ sở dữ liệu đó và chủ sở hữu là người duy nhất thực hiện thay đổi cơ sở dữ liệu.

Khi việc xây dựng trang web tiến xa hơn một chút, trang web sẽ được đặt trên một máy chủ. Từ thời điểm đó, cơ sở dữ liệu của máy chủ là hợp quy. Mọi người (bao gồm cả chủ sở hữu) phải thực hiện tất cả các thay đổi cơ sở dữ liệu trên máy chủ và kéo các thay đổi xuống để phát triển và thử nghiệm cục bộ.

Quá trình này không hoàn hảo. Vẫn có khả năng ai đó có thể cần thực hiện các thay đổi trong phần phụ trợ WordPress cục bộ trong quá trình phát triển và sau đó phải thực hiện lại những thay đổi đó trong sản xuất. Tuy nhiên, chúng tôi thấy rằng đó là điều hiếm gặp và quá trình này hoạt động khá tốt đối với chúng tôi.


1

Tôi làm việc trên một cài đặt như vậy và đã trả lời các câu hỏi như thế này trước đây . Dưới đây là thiết lập ưa thích của tôi cho loại công việc này. Vì bạn muốn hợp nhất cơ sở dữ liệu thay vì thay thế cơ sở dữ liệu hiện có, tôi nên thêm vào những điều này một cách thận trọng không sử dụng cờ --add-drop-bảng khi thực hiện kết xuất MySQL.


  • Bước 1. Mysqldump cơ sở dữ liệu phát triển của bạn
  • Bước 2. Thay thế tất cả các phiên bản của Development.domain.com thành Production.domain.com ^^
  • Bước 3. Đăng nhập vào MySQL, chạy lệnh SOURCE để nhập dữ liệu, vd source /path/to/file

^^ Cách thay thế tất cả các phiên bản của tên miền cũ bằng mới: (1) Sao chép tập lệnh bên dưới. (2) chmod +xnó. (3) Chạy nó.

Sử dụng: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

2
Hãy cẩn thận: sed không thể xử lý dữ liệu được mã hóa bên trong các bãi chứa mysql đã được tuần tự hóa trước đó.
hakre

câu hỏi bạn trả lời trước đây là của tôi, trên thực tế :) Tôi cảm thấy như tôi đang hỏi một câu hỏi khác ở đây. Thật tuyệt khi kết xuất toàn bộ DB khi tôi chỉ làm việc với nó, nhưng nếu tôi làm điều đó trong tình huống được mô tả ở trên, tôi sẽ ghi đè lên các thay đổi của người khác hoặc ghi đè lên các thay đổi của chính tôi. Tôi đang tìm cách kết hợp các thay đổi khi có nhiều người làm việc trên các phiên bản WordPress.
Gavin Anderegg

1

Tôi đang thử nghiệm các giải pháp khác nhau cho cùng một vấn đề ngay bây giờ. Đó chắc chắn là một khó khăn.

Giải pháp hiện tại của tôi là thực hiện kết xuất mysql cục bộ bằng cách sử dụng cờ --skip-extend-insert. Tôi tin rằng cờ này làm cho một câu lệnh chèn bản ghi được tạo cho mỗi hàng của cơ sở dữ liệu, làm cho kết xuất trở nên thân thiện hơn một chút. Tôi đã chọn thủ thuật đó từ bài viết này: http://www.viget.com/extend/backup-your-database-in-git/ .

Sau đó, tôi kiểm soát nguồn kết quả tệp dữ liệu .sql bằng Git cùng với các tệp nguồn của trang web. Khi một nhà phát triển khác kéo xuống các thay đổi mã, tệp .sql đi kèm với nó. Sau đó, anh ta nhập tệp này vào phiên bản cơ sở dữ liệu cục bộ của mình. Cả hai chúng tôi đều thiết lập cơ sở dữ liệu cục bộ tương ứng trên cả hai máy, sử dụng MAMP, do đó không cần thực hiện bất kỳ tìm kiếm và thay thế nào.

Đã có những vấn đề hợp nhất vì vậy chúng tôi đang cố gắng áp dụng cách tiếp cận "thay phiên nhau" cho bất kỳ điều gì sẽ gây ra thay đổi cơ sở dữ liệu. Trước khi tôi làm bất cứ điều gì trong Wordpress sẽ thay đổi cơ sở dữ liệu, tôi chắc chắn rằng anh ấy đã kiểm tra bãi rác mới nhất của anh ấy, kéo và nhập nó, và yêu cầu anh ấy không thực hiện bất kỳ thay đổi DB nào cho đến khi tôi thực hiện và kiểm tra trong tôi. Điều này rõ ràng không lý tưởng và tôi đang tìm kiếm một giải pháp tốt hơn nhưng đó là một sự khởi đầu. Nó cũng cung cấp cho chúng tôi phiên bản kiểm soát DB rất tốt.

Tôi có thể kết thúc việc thiết lập cho chúng tôi một cơ sở dữ liệu dev được chia sẻ trên máy chủ và thử kết nối cả hai bản sao trang web cục bộ của chúng tôi với cùng một DB thông qua đường hầm SSH. Cách tiếp cận này, tuy nhiên, sẽ gặp vấn đề bất cứ khi nào một trong số chúng tôi cài đặt một plugin. Về cơ bản các tệp PHP và MySQL DB sẽ không đồng bộ.

Tôi rất muốn nghe cách những người khác đang giải quyết vấn đề này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.