Làm cách nào để hợp nhất các thay đổi từ bản sao phát triển của trang web sang trang trực tiếp mà không mất nội dung mới?


40

Quy trình tốt nhất để hợp nhất công việc được thực hiện trên bản sao phát triển của trang web với bản sao sản xuất trực tiếp là gì? Thông thường, đã có rất nhiều nội dung mới được thêm vào trang web kể từ khi phát triển bắt đầu với các tính năng mới nhất. Và hầu hết các bổ sung cho một trang web sẽ liên quan đến thay đổi cơ sở dữ liệu. Vì vậy, sao chép bất kỳ tập tin mới là dễ dàng, nhưng cơ sở dữ liệu thì sao? Làm cách nào để hợp nhất các thay đổi của bạn với cơ sở dữ liệu sản xuất hiện có mà không làm mất nội dung mới được thêm vào kể từ lần cuối bạn cập nhật trang web sản xuất? Có mô-đun nào giúp với điều này?


2
Xóa nhầm lẫn: Hợp nhất & di chuyển là hai từ khác nhau. Bạn đã sử dụng cả hai trong câu hỏi của bạn. Nếu trang web trực tiếp trống, bạn cần di chuyển bản sao phát triển sang trang / máy chủ trực tiếp. Nếu trang web trực tiếp đã có nội dung, cần phải hợp nhất nội dung mới từ bản sao phát triển sang trang trực tiếp (Việc hợp nhất có phần khó khăn). Bạn cần làm gì?
user931

Câu trả lời:


16

Đối với các loại nội dung, chế độ xem và thay đổi cấu trúc trên trang nhà phát triển, hãy xem sử dụng Tính năng để xuất cơ sở dữ liệu sang mã.

Đối với di chuyển nội dung có nhiều tùy chọn, nhưng không phải là một giải pháp vững chắc. Một ví dụ là bộ Deployment .


bộ Demployment chắc chắn trông rất thú vị, mặc dù nó vẫn ở Dev (thậm chí chưa phải là bản Beta). Bạn đã sử dụng nó cho mình? Bạn có biết bất cứ điều gì nó sẽ không bao gồm?
Chaulky

2

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. Tùy chọn, chạy một tìm kiếm / thay thế regex 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à:

  1. 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
  2. Kiểm soát phiên bản tùy chọn (và hy vọng)
  3. Tải tập tin trên hệ thống prod
  4. Sử dụng giao diện drush hoặc admin để tải các tính năng
  5. Sử dụng drush xóa-all 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
  6. 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.


Trong tùy chọn 1, làm thế nào để bạn tạo lại nội dung đã được thêm vào trang web trực tiếp không có trong trang dev? Có vẻ như bạn đang ghi đè tất cả bằng db db và sau đó có thể thay đổi một số cài đặt / biến. Ngoài ra, trường tư tưởng nào bạn đang sử dụng trên các trang web của bạn hiện tại? Bất kỳ ưu và nhược điểm cho mỗi phương pháp?
Chaulky

Trong tùy chọn 1, bây giờ chúng tôi sử dụng node_export để thường xuyên gửi nội dung (đã xóa nội dung trước đó). Chúng tôi đã từng thay đổi nội dung trên cả dev và prod. Đây thực sự là một kịch bản phổ biến ở một vài nơi tôi đã thấy, mặc dù rõ ràng là không lý tưởng. Đây là lý do tại sao tôi thêm, chấp nhận một hướng và gắn bó với nó, hoặc là nội dung đi dev -> prod hoặc prod -> dev, nhưng cố gắng không làm cả hai. Và vâng, về cơ bản chúng tôi đã ghi đè lên, mặc dù giống như xóa và xây dựng lại. Ở công việc mới của chúng tôi, chúng tôi làm số 2, tại công việc cũ của tôi, chúng tôi đã làm số 1 nhưng đang chuyển sang số 2 (tôi vẫn đang tư vấn cho họ).
coderintherye

1

Cơ sở dữ liệu kết xuất của bản sao trang web phát triển và bản sao phát triển của trang web trong tệp SQL (sử dụng cùng một tham số & cài đặt cho cả hai bãi chứa).
Sau đó, so sánh cả hai tệp SQL bằng cách sử dụng một công cụ so sánh nhỏ TestDiff . Nó sẽ hiển thị các tệp khác nhau cạnh nhau với các màu khác nhau. Bạn cũng có thể trực tiếp chuyển đến sự khác biệt (không cần cuộn). Kiểm tra sự khác biệt và thêm / chỉnh sửa các dòng vào tệp SQL của trang web trực tiếp. Đảm bảo không có đường dẫn / URL tuyệt đối của môi trường phát triển trong tệp đó. Đã xong! Thời gian để khôi phục cơ sở dữ liệu cho trang web trực tiếp.
Làm cho cuộc sống của bạn dễ dàng hơn:Trong bước đầu tiên, chỉ kết xuất những bảng được thay đổi. Ví dụ: nếu bạn đã chỉnh sửa một mô-đun trong bản sao phát triển nhắm mục tiêu một bảng riêng biệt, chỉ kết xuất bảng này. Nếu bạn không chắc chắn về bảng cụ thể, toàn bộ cơ sở dữ liệu sẽ ổn.


Kỹ thuật này có những hạn chế nghiêm trọng trong một số trường hợp quan trọng. Ví dụ: nếu trang web phát triển có các nút mới, thì hai cơ sở dữ liệu của bạn sẽ chứa cả các mục có cùng id nút và sẽ không thể giải quyết các tham chiếu và hợp nhất chúng từ kết xuất văn bản của cơ sở dữ liệu sql. Loại hoạt động này được xử lý tốt hơn thông qua các tính năng và triển khai, như được đề cập trong các câu trả lời khác.
greg_1_anderson
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.