Làm cách nào để quản lý sự phát triển hợp tác trên trang web Drupal?

Tôi làm việc với một nhà phát triển khác trên một trang web Drupal. Chúng tôi đã đấu tranh để tìm ra một cách tốt để làm việc trên các phần khác nhau của trang web cùng một lúc mà không gặp nhau. Chúng tôi đã thử làm việc trên cùng một phiên bản phát triển của trang web, nhưng chúng tôi thường giẫm lên các ngón chân của nhau hoặc đưa trang web xuống với một số mã xấu khiến cho trang kia không thể tiếp tục hoạt động cho đến khi giải quyết xong. Vì vậy, chúng tôi đã chuyển sang các trường hợp phát triển riêng biệt. Nhưng bây giờ, đó là một nỗi đau lớn để hợp nhất công việc của chúng tôi vào một ví dụ duy nhất của trang web. Về cơ bản, chúng tôi cuối cùng đã làm lại mọi thứ trên một bản sao được chia sẻ.

Vấn đề lớn nhất hiện nay của chúng tôi là làm cách nào để hợp nhất các thay đổi cơ sở dữ liệu và làm cách nào để đưa cơ sở dữ liệu vào hệ thống kiểm soát nguồn của chúng tôi? Các tập tin rất dễ dàng, chỉ cần theo dõi tất cả (chúng tôi sử dụng git) và hợp nhất công việc của chúng tôi, giải quyết xung đột khi cần thiết. Nhưng điều này không thực sự hoạt động với cơ sở dữ liệu. Chúng tôi có thể lấy một kết xuất SQL và đưa nó vào kho git của chúng tôi, nhưng chúng tôi thực sự không thể hợp nhất các cơ sở dữ liệu. Các mô-đun tính năng giúp một chút, cho phép chúng ta xuất khẩu một số công việc cơ sở dữ liệu của chúng tôi vào mã mà sau đó có thể được phiên bản và sáp nhập. Tuy nhiên, thậm chí không gần với mọi thứ hỗ trợ Tính năng. Vì thế...

• Những bước nào chúng ta có thể thực hiện để dễ dàng hợp nhất các thay đổi cơ sở dữ liệu của chúng tôi?

• Làm thế nào chúng ta nên phiên bản cơ sở dữ liệu (đặt một tệp kết xuất trong git một cách tốt để làm điều đó)?

• Có bất kỳ mô-đun có sẵn nào giúp giải quyết một số vấn đề này không?

• Hoặc, có phải chúng ta bị mắc kẹt với việc làm việc trên cùng một bản sao của trang web? (xin vui lòng không)

Chỉnh sửa: Trong các nhận xét, chúng tôi đã thảo luận về những thứ không thể xuất khẩu với Tính năng và một trong số đó là Phân loại. Có một câu hỏi khác liên quan đến điều đó .

Đó là một thay đổi quy trình công việc nhưng bạn sẽ quen với việc làm việc trên một bãi chứa DB mới. Có ba cách để thay đổi DB.

1. Đặc trưng. Điều này sẽ không làm việc cho tất cả mọi thứ nhưng sẽ cho rất nhiều thứ bạn cần.
2. cập nhật móc. Khi các tính năng không hoạt động, bạn có thể mã hóa mọi thứ vào một bản cập nhật của mô-đun bạn sở hữu.
3. Hướng dẫn thay đổi. Sử dụng một cách tiết kiệm. Một số điều không tự nhiên đến với các tính năng hoặc cập nhật các hook và dễ dàng thực hiện thủ công hơn nhiều. Đây là một phương sách cuối cùng nhưng đôi khi là cách cướp biển duy nhất.

Nếu bạn có thể. Một vài lần một ngày nhận được một bãi chứa mới và kiểm tra bản dựng của bạn, bạn sẽ có ít vấn đề tích hợp hơn.

Tôi đã trả lời một câu hỏi tương tự và tôi sẽ điều chỉnh nó một chút để trả lời câu hỏi của bạn ở đây. Đề xuất gốc của tôi là bạn có một máy chủ phát triển / dàn dựng trong đó các thay đổi mã được kiểm tra bằng hệ thống tích hợp liên tục một cách thường xuyên (ví dụ: cứ sau 5 phút). Do đó, trên máy cục bộ của bạn, bạn chỉ làm việc trên một báo cáo yêu cầu / lỗi tính năng tại một thời điểm, đảm bảo phân định rõ ràng nhiệm vụ này với những người khác mà mọi người có thể đang làm việc và thông báo cho đồng đội của bạn rằng bạn đang làm việc với nó (redmine hoặc theo dõi lỗi khác là tuyệt vời cho việc này). Sau đó, bạn cam kết thay đổi một cách thường xuyên và chúng được kéo xuống máy chủ dev / staging, cũng như các đồng đội của bạn. Lý tưởng nhất là bạn có các bài kiểm tra đơn vị được tích hợp trong hệ thống tích hợp liên tục của bạn (rất khuyến khích luntbuild hoặc QuickBuild cho việc này bằng cách này, nhưng Hudson cũng hoạt động). Hệ thống CI hoặc kiểm tra có thể tự động nhận bất kỳ xung đột nào bạn có thể đã giới thiệu ngay khi bạn kiểm tra mã của mình. Nếu bạn cần thay đổi nội dung (không phải mã), bạn sẽ làm như vậy trên máy chủ dev / staging.

Về phần cơ sở dữ liệu, về cơ bản, tôi đã áp dụng hai trường phái tư tưởng (trường phái tư tưởng thứ 3, làm cơ sở dữ liệu khác nhau, tôi sẽ không thảo luận vì độ phức tạp khá cao).

1) Triển khai bằng cách loại bỏ cơ sở dữ liệu sản xuất và nhập một mysqldump của cơ sở dữ liệu phát triển. Theo tùy chọn, hãy chạy regex find / thay thế trước trên bất kỳ liên kết tuyệt đối được mã hóa cứng nào tham chiếu URL dev trong kết xuất SQL. Sau khi nhập dev db vào prod, sau đó tự động chạy các câu lệnh SQL (thường thông qua tập lệnh) để thay đổi bất kỳ cài đặt nào khác với prod so với dev (ví dụ: có thể bạn có trong bảng biến một số cài đặt kết nối để kết nối với các hệ thống bên ngoài mà bạn cần thay đổi thành điểm tại các hệ thống bên ngoài thay vì ở phiên bản dev).

2) Sử dụng mô-đun Tính năng, như được đề cập bởi phật, cho cài đặt quản trị viên và sử dụng mô-đun Xuất nút để xuất / nhập nội dung kết hợp với mô-đun Xóa tất cả. Vì vậy, quy trình làm việc là:

sử dụng node_export và các tính năng để xuất các nút / tính năng sang tệp Tùy chọn (và hy vọng) kiểm soát phiên bản Tải tệp trên hệ thống prod Sử dụng giao diện drush hoặc quản trị viên để tải các tính năng Sử dụng drush xóa tất cả hoặc giao diện quản trị để xóa tất cả các nút của loại bạn muốn nhập Sử dụng drush ne-import hoặc giao diện quản trị để nhập các nút từ tệp nút bạn đã xuất. Một lưu ý, tôi rất khuyến nghị nên áp dụng quy trình làm việc tiêu chuẩn, trong đó nội dung chỉ đi theo một hướng. Hoặc Dev -> Prod hoặc Prod -> Dev (Tôi thích cái này).

Tôi đã làm điều này và đang thực hiện điều này trên một số hệ thống lớn, với kết quả khá tốt, nhưng sẽ luôn có nhiều cách để cắt quả táo này, chọn cách nào phù hợp nhất với bạn.

Mặc dù đây là một câu hỏi cũ với một câu trả lời được chấp nhận, tôi tin rằng vẫn còn chỗ cho một câu hỏi khác.

Trước tiên, hãy để tôi nói trước rằng tôi không nghĩ Tính năng là công cụ phù hợp cho nhiệm vụ này và sẽ đề xuất một bộ công cụ thay thế.

Một điều kiện tiên quyết để hợp tác nhóm là phải có một máy chủ dàn để thử nghiệm các phiên bản phát triển của dự án tách biệt với máy chủ sản xuất của bạn. Tất cả mã devlopment được kiểm tra tại máy chủ dàn và chỉ được đẩy đến máy chủ sản xuất khi nó ổn định và sẵn sàng để triển khai. Tuy nhiên, các nhà phát triển không làm việc trực tiếp tại máy chủ dàn. Mỗi nhà phát triển làm việc tại máy trạm riêng của mình, sử dụng điều khiển sửa đổi và quản lý mã nguồn (SCM) để phối hợp công việc của mình với phần còn lại của nhóm.

Hệ thống SCM cho phép các thành viên trong nhóm làm việc song song trên các nhánh mã khác nhau mà không can thiệp lẫn nhau. Chỉ có chủ chi nhánh được triển khai trên các máy chủ trung gian cho các mục đích thử nghiệm.

Để phản ánh cơ sở dữ liệu giữa sản xuất, dàn dựng và máy trạm, có một mô-đun có tên Sao lưu và di chuyển có thể được sử dụng nếu bạn đang lưu trữ chia sẻ và không quản lý cơ sở dữ liệu của riêng bạn. Nếu bạn đang quản lý máy chủ cơ sở dữ liệu của riêng mình, đây là dự án duy nhất trên máy chủ đó và bạn sử dụng mysql , cặp lệnh sau đây rất tiện dụng:

Để đổ:

mysqldump --all-databases --opt -u root -p > DUMP.sql

Để khôi phục lại:

mysql -u root -p < DUMP.sql

Nếu cơ sở dữ liệu của bạn không phải là cơ sở dữ liệu duy nhất trên máy chủ đó, hãy tạo một số phiên bản mysqldump(hoặc tương đương nếu bạn không sử dụng mysql ) mà chỉ hủy cơ sở dữ liệu của bạn.

Tạo một chính sách rằng đó là cơ sở dữ liệu trên máy chủ sản xuất là chủ. Máy chủ dàn và máy trạm phải là bản sao của cơ sở dữ liệu sản xuất, không phải ngược lại.

Lưu ý rằng Drupal 7 giữ tất cả cài đặt quản trị viên trong cơ sở dữ liệu. Điều này có nghĩa là phản chiếu cơ sở dữ liệu giữa trang sản xuất, trang dàn và máy trạm sẽ di chuyển các cài đặt đáng ngưỡng mộ mà không có Tính năng .

Bây giờ, để chia sẻ mã:

Cách tiêu chuẩn để chia sẻ mã giữa các thành viên của nhóm phát triển là sử dụng hệ thống SCM. Drupal mặc định được quản lý với một hệ thống có tên git .

Git cho phép sử dụng các kho lưu trữ cục bộ hoặc từ xa. Nếu các thành viên trong nhóm được đặt trong cùng một không gian vật lý, bạn có thể thiết lập một kho lưu trữ cục bộ trên máy chủ dàn của mình. Nếu chúng lan truyền theo địa lý, bạn có thể thiết lập một repositiory từ xa. Nếu bạn không bận tâm đến việc người khác có quyền truy cập đọc mã của bạn đang được phát triển, bạn có thể sử dụng hộp cát tại Drupal.org làm kho lưu trữ từ xa. Bạn cũng có thể sử dụng một khu vực dự án trên GitHub . GitHub không chỉ là một kho lưu trữ, mà còn đi kèm với một số công cụ để cộng tác và cho phép cả kho lưu trữ công cộng và riêng tư.

Về cơ bản, hệ thống SCM cho phép các thành viên trong nhóm lấy mã nguồn và tài liệu từ kho lưu trữ được chia sẻ bởi các thành viên trong nhóm và đẩy nó trở lại sau khi đã làm việc với nó. SCM theo dõi các thay đổi và nếu có xung đột (nghĩa là ai đó cố gắng đẩy mã không chứa các thay đổi mà thành viên nhóm đã cam kết), nó sẽ cho bạn biết và cũng đề xuất cách giải quyết xung đột này.

Thông thường, với một số giao tiếp thân mật về cách phân chia nhiệm vụ giữa các thành viên trong nhóm, sẽ không có xung đột. Nhưng với hệ thống SCM theo dõi mọi thứ, các xung đột trở nên có thể kiểm soát được ngay cả khi có lỗi hoặc giao tiếp thất bại.

Có rất nhiều hướng dẫn về việc bắt đầu và sử dụng git (GIYF). Hai tôi sẽ giới thiệu là: trang web git-scm và Pro Git của Scott Chacon.