Làm thế nào để loại bỏ chính xác một mô-đun trong một môi trường dàn dựng?


17

Một số mô-đun có thói quen khử kết tinh. Mà thường loại bỏ cơ sở dữ liệu cho mô-đun đó, các biến từ bảng biến và các vị trí được mô-đun đó giới thiệu. Những thói quen này sống trong .installmô-đun đó.

Do đó, chúng không thể được chạy nếu không có mô-đun đó. Vì vậy, đây là các bước hiện tại của chúng tôi. Câu hỏi của tôi là: điều này có thể được thực hiện đơn giản và hiệu quả hơn? Nói rằng tôi loại bỏ mô-đun foo_bar.

  1. Trong RCS, chuẩn bị một bản phát hành mới, trong đó:
    • Tất cả các ghi đè css và chủ đề sử dụng hoặc xây dựng trên đầu trang của foo_bar đều bị xóa.
    • Tất cả các ghi đè css và chủ đề cho các mô-đun tùy thuộc vào foo_bar đều bị xóa.
  2. Đẩy bản phát hành đó đến sự chấp nhận. Kiểm tra sự kết tinh (từ quản trị viên / mô-đun) với một bản sao rất gần đây của cơ sở dữ liệu sản xuất.
  3. Nếu mọi việc suôn sẻ, hãy triển khai cơ sở mã mới vào sản xuất và hủy bỏ foo_bar và các phụ thuộc của nó ở đó. Điều này sẽ gọi gỡ cài đặt trong các mô-đun khác nhau, làm sạch cơ sở dữ liệu.
  4. Trong RCS (git), chuẩn bị một bản phát hành mới trong đó mã thực sự bị xóa.
  5. Triển khai để chấp nhận nơi chúng tôi kiểm tra nếu không có gì vô tình phụ thuộc vào điều này (một số mô-đun hoặc chức năng chủ đề xấu bao gồm các tệp trực tiếp từ các mô-đun khác. Đáng chú ý nhất là CSS, JS hoặc tệp hình ảnh).
  6. Nếu được chấp nhận, triển khai phát hành mới vào sản xuất. sản xuất hiện có một cơ sở dữ liệu sạch và một cơ sở mã sạch .

Vấn đề mà tôi không thể thấy cách giải quyết, đó là điều này luôn cần hai bản phát hành. Vì trong Drupal, một bản phát hành yêu cầu trang web phải ngoại tuyến, điều này có nghĩa là hai lần ngừng hoạt động chỉ để xóa một mô-đun. Nó cũng đòi hỏi hai thủ tục phát hành, trong đó, trong môi trường lưu trữ chuyên nghiệp có thể rất tốn kém, tốn thời gian hoặc bực bội.

Nếu chúng ta loại bỏ mô-đun khỏi codebase trong lần lặp đầu tiên, chúng ta không thể chạy các hook gỡ cài đặt, giữ nhiều lint trong cơ sở dữ liệu; không chỉ một vài bảng, mà chủ yếu là các biến và địa phương. Nếu chúng ta không loại bỏ mô-đun khỏi cơ sở mã, điều đó có nghĩa là cơ sở mã sẽ phát triển với mã cũ, không sử dụng; điều này không mang lại hiệu năng cao, nhưng làm cho việc duy trì mã ngày càng khó hơn.

Làm thế nào để bạn đối phó với điều này?

[chỉnh sửa: thêm ghi chú về việc triển khai là một thủ tục khó khăn, thường]


2
Nếu trước tiên bạn thực hiện các bước 1 - 6 trên máy chủ dàn, bạn không thể cập nhật trang web trực tiếp lên CHÍNH ^, thực hiện gỡ cài đặt, sau đó cập nhật lên CHÍNH (tất cả trong một lần ngồi)?
Andy

Nếu tất cả các dự án của tôi được triển khai git, thì có. Nhưng một số cần tarball để được gửi xung quanh, trong khi những người khác sử dụng (chỉ!) Ftp và như vậy. Nhưng nhìn vào git, và một số git-hook-scripts chắc chắn là một ý tưởng rất thú vị.
cập bến

Tại sao chính xác là cần thiết để đưa trang web xuống?
Letharion

@Letharion: 1) Đưa trang web xuống cấm ghi không mong muốn vào cơ sở dữ liệu của bạn trong quá trình thay đổi cơ sở dữ liệu đó; Drupal không sử dụng Giao dịch. 2) Triển khai mã mới phụ thuộc vào trạng thái cơ sở dữ liệu nhất định (một chủ đề yêu cầu một trường cck nhất định, ví dụ) sẽ phá vỡ trang web của bạn trong thời gian giữa việc tung ra mã và cập nhật cơ sở dữ liệu.
cập bến

Câu trả lời:


7

Hãy cẩn thận về việc giữ cho cơ sở dữ liệu và mã của bạn được đồng bộ; như bạn đã đề cập trong câu hỏi của mình, các mô-đun được gỡ cài đặt cần phải ở trong cơ sở mã cho đến khi các móc gỡ cài đặt của chúng được chạy trên cơ sở dữ liệu trực tiếp. Đây là một hạn chế của Drupal mà một công việc git pull một mình sẽ không giải quyết được.

Tôi sẽ khuyên bạn thay vì cố gắng điều chỉnh quy trình của mình, thay vào đó, bạn nên tìm cách giảm thời gian chết cần thiết để xử lý các cập nhật của mình. Tôi khuyên bạn nên thiết lập một môi trường dàn sao ying / yang để giải quyết vấn đề này. nb Tôi chưa sử dụng các tập lệnh có trong liên kết trước; bạn có thể muốn thiết lập mọi thứ khác nhau, theo cùng một ý tưởng rằng bạn có thể trao đổi các trang web trực tiếp và giai đoạn của mình trong khi triển khai.

Tiếp tục làm theo quy trình tương tự bạn đã nêu trong câu hỏi của mình với các điều chỉnh sau:

a. Đồng bộ hóa từ dev đến giai đoạn (yang) như bình thường. Kiểm tra bằng cách thực hiện gỡ cài đặt các mô-đun sẽ bị xóa sau khi xóa mã, v.v. ghi đè & c. loại bỏ, vv khi cần thiết. Có lẽ chỉ cần hai tài liệu tham khảo.

b. Khi kiểm tra hoàn tất và được chấp nhận, khôi phục mã trên sân khấu (yang) về trạng thái sống (ying).

c. Chuẩn bị trang web trực tiếp (ying) để cập nhật bằng cách vô hiệu hóa bất kỳ khả năng nào của người dùng để thay đổi nội dung trên hệ thống. Một bản cập nhật sql cho bảng quyền thường sẽ làm ở đây. Tại thời điểm này, người dùng vẫn có thể đọc nội dung trên trang web trực tiếp, nhưng sẽ bị lỗi từ chối cấp phép nếu họ cố cập nhật nội dung. (Nếu bạn tuyệt vời, có lẽ bạn có thể thay đổi trình xử lý bị từ chối cấp phép để in một thông báo thích hợp rằng chức năng này tạm thời không khả dụng).

d. Bây giờ đẩy cơ sở dữ liệu (ying) trực tiếp trở lại cơ sở dữ liệu giai đoạn (yang), ngoại trừ bảng quyền từ bản cập nhật.

e. Lặp lại bước a. lần nữa. Nếu bạn có các hashtag tiện dụng, bạn có thể dễ dàng khôi phục về trạng thái tồn tại các mô-đun cần xóa, chạy các móc gỡ cài đặt trên cơ sở dữ liệu và sau đó quay lại trạng thái mã nơi các mục của bạn từ bước 1 được hợp nhất trở lại.

f. Bây giờ bạn đã sẵn sàng để trao đổi ying và yang. Làm điều này bằng cách điều chỉnh các chỉ thị cấu hình Apache của bạn. Lưu ý rằng nếu bạn thực hiện /etc/init.d/apache restart, một số kết nối có thể bị hủy nhưng /etc/init.d/apache reloadsẽ cho phép trao đổi sạch.

g. Sống bây giờ là 'yang'; bảng quyền không được sửa đổi ở đây, vì vậy người dùng có thể tạo nội dung. Nếu bạn tự động hóa các bước e. và f., thời gian không có sẵn nên rất thấp.

h. Đẩy live (yang) trở lại giai đoạn (ying), cả mã và cơ sở dữ liệu - hoặc đẩy từ dev, khi cần. Bây giờ bạn có một môi trường sạch sẽ sẵn sàng cho lần lặp tiếp theo của bạn.


Ying-yang thất bại khủng khiếp trên bước c. Chỉ các trang web rất cụ thể, chẳng hạn như chỉ biên tập theo định hướng-anon-access-only mới hoạt động. Điều đó chủ yếu là vì không chỉ các bình luận, các nút và như vậy phải bị vô hiệu hóa, mà bảng phiên, bộ giám sát, bộ đếm, vv sẽ được cập nhật và ghi vào. Thời gian chết có vẻ là một tác dụng phụ đáng tiếc, nhưng không thể khắc phục. Mặc dù, thực sự, đối với một số trang web nhất định, ying-yang là một khái niệm rất thú vị để sử dụng khi triển khai.
cập bến

Tất nhiên bạn đúng; tuy nhiên, nếu bạn viết kịch bản bước cuối cùng, cửa sổ thời gian chết hoặc thông tin bị mất sẽ thấp. Nếu bạn mất một mục từ bảng phiên, người dùng sẽ phải đăng nhập lại. Một quầy có thể được tắt một chút. Bạn có thể bỏ lỡ một hoặc hai thông báo trong cơ quan giám sát. Nếu điều này tồi tệ hơn một khoảng thời gian ngắn "trang web này không hoạt động để bảo trì", thì bằng mọi cách, hãy sử dụng giải pháp đơn giản hơn. Nếu bạn thực sự muốn, bạn có thể cố gắng khôi phục các tin nhắn truy cập và theo dõi sau khi trao đổi. Điều này có thể phức tạp hơn giá trị của nó, trừ khi thông tin + thời gian RẤT có giá trị.
greg_1_anderson

Bạn có thể xem xét theo dõi các giao dịch trên trang web chuyển đổi bằng cách sử dụng nhật ký nhị phân mysql. Xem dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html . Tôi sẽ miễn cưỡng khi chỉ hợp nhất mọi thứ lại với nhau, nhưng bạn có thể theo dõi thêm các tin nhắn phản đối / theo dõi ngoài nhóm. Cách dễ nhất để đối phó với bảng phiên cũng là vô hiệu hóa đăng nhập trong quá trình chuyển đổi.
greg_1_anderson

Nhận xét của bạn đưa tôi đến một giải pháp khả thi khác: tổng hợp tất cả các hook_uninstall của một mô-đun dưới dạng hook_update_n () của một mô-đun có mục đích đặc biệt: Uninstall.module. Bằng cách đó, tôi có thể loại bỏ cơ sở mã trong lần lặp đầu tiên / và / nhận được sự kết tinh nhanh hơn nhiều trong bản phát hành thực tế. Có thể là một kịch bản drush để loại bỏ thông tin này.
cập bến

1
Một điều nữa sẽ giúp một chút. Thay đổi tất cả mã php tùy chỉnh của bạn sao cho mọi tham chiếu đến mô-đun cần xóa được gói vào if (module_exists('removeme')) { ... }. Triển khai mã đó. Nếu bạn kiểm tra và xác nhận rằng việc xóa mô-đun không còn phá vỡ mã tùy chỉnh của bạn, điều đó sẽ đơn giản hóa việc triển khai của bạn. Bạn vẫn nên thực hiện bước vô hiệu hóa trên một trang web không tồn tại, nhưng có lẽ điều này sẽ thu hẹp cửa sổ của bạn một chút. Tôi không nghĩ rằng hook cập nhật tùy chỉnh của bạn sẽ giúp việc vô hiệu hóa mô-đun trực tiếp trở nên an toàn hơn.
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.