Làm cách nào để sử dụng mô-đun Tính năng trong môi trường 3 dev?


19

Làm việc trên một dự án, sử dụng nhiều tính năng , đôi khi có 3 nhà phát triển cho ứng dụng này.

Chúng tôi đã thử một vài cách tiếp cận, nhưng khi chúng tôi hợp nhất các nhánh git của mình, có vẻ như chúng tôi thường 'viết quá nhiều' các thay đổi tính năng của nhau. Xung đột rất nhiều, phá vỡ các mô-đun tính năng làm cho nó đau khi sử dụng, dường như.

Các tính năng thực sự là một trình tiết kiệm thời gian tuyệt vời cho cấu hình cho một dự án và tôi khá chắc chắn rằng có một cách để giải quyết vấn đề này.

Có một quy trình hoặc thủ tục làm giảm rủi ro xung đột và ghi đè?

Bất kỳ manh mối về các tính năng đều được chào đón.

Câu trả lời:


20

Chào mừng bạn đến vùng đất của F eatures C onfiguration M anagement, aka FCM ! Nó không chỉ là về Tính năng , mà không phải về Quản lý cấu hình (như được giới thiệu trong phiên bản 8 của Drupal). Thay vào đó, nó là một trường hợp đặc biệt của S oftware C onfiguration M anagement , aka SCM . Chủ yếu là vì các Tính năng có thể được coi là một trình tạo mã, trong khi đó mã được tạo cần phải được di chuyển qua nhiều môi trường. Đọc để biết thêm chi tiết.

1 - Ưu và nhược điểm của việc sử dụng Tính năng

Ưu điểm của việc sử dụng các tính năng

  • Tự động hóa việc triển khai các thay đổi được áp dụng cho một trang web phát triển Drupal đến một hoặc nhiều trang web sản xuất Drupal (trước) (thay vì triển khai thủ công).
  • Tạo điều kiện chia sẻ (vận chuyển) sự phát triển Drupal đang diễn ra giữa các nhà phát triển / người xây dựng trang web Drupal (ví dụ: để tạo một số Chế độ xem được tạo bởi một chuyên gia về quan điểm có sẵn cho một Drupal Themer làm việc trong một trang web phát triển khác để xem chủ đề đó).
  • Tích hợp tuyệt vời với cả GIT và Drush để vận chuyển một bản sao của mã được tạo bởi Tính năng (trên trang web phát triển) đến các trang web sản xuất mục tiêu (trước) được chọn.

Nhược điểm của việc sử dụng các tính năng

  • Tránh xung đột tính năng và / hoặc quản lý phụ thuộc tính năng có thể là thách thức!
  • Không dễ để bắt đầu sử dụng Tính năng trên một trang web (sản xuất) hiện có.
  • Cài đặt / kích hoạt mô-đun Tính năng rất dễ dàng (chỉ là mô-đun), nhưng để tìm hiểu cách sử dụng Tính năng chính xác là một thách thức lớn.

2 - Kỹ thuật đóng gói tính năng

Sử dụng Tính năng tùy thuộc vào trí tưởng tượng của bạn về cách đóng gói (soạn) nội dung của một tính năng. Dưới đây là một số kỹ thuật có thể được sử dụng cho nó.

Một siêu tính năng duy nhất

Đây là một kỹ thuật đóng gói khá đơn giản: mọi thứ được đóng gói cùng nhau trong một tính năng duy nhất (một số người gọi đó là tính năng "Thần" ...). Có vẻ dễ dàng, khá dễ dàng, vv Nhưng kỹ thuật này cũng dẫn đến "xung đột" (như được giải thích dưới đây) ít nhiều ngay lập tức ...

Một cách sử dụng tốt cho điều này dường như là khi tạo ra một "phân phối Drupal", trong đó tất cả người dùng của nó được cho là sử dụng cùng một bộ mô-đun, cấu hình, v.v. Tuy nhiên, nếu phân phối như vậy bao gồm nhiều chức năng trang web (không sử dụng từ này "Các tính năng" ...), có vẻ phù hợp hơn khi phân chia các tính năng đó trong nhiều tính năng, như được giải thích bên dưới.

Dựa trên chức năng trang web

Kỹ thuật đóng gói này tạo ra một tính năng riêng biệt cho từng chức năng của trang web, chẳng hạn như:

  • Tính năng A = thực hiện " * Thư viện ".
  • Tính năng B = hiện thực một " * Blog ".
  • Tính năng C = thực hiện " * Lịch sự kiện ".

Dựa trên các phần quản trị Drupal

Kỹ thuật đóng gói này tạo ra các tính năng riêng biệt cho từng phần quản trị (chính) của trang web Drupal được sử dụng để tạo trang web, chẳng hạn như:

  • Tất cả các mô-đun cần thiết được chứa trong tính năng A,
  • Tất cả các định nghĩa trường cơ sở được chứa trong tính năng B,
  • Tất cả các loại nội dung được chứa trong tính năng C,
  • Tất cả các quyền được chứa trong tính năng D,
  • Tất cả các vai trò được chứa trong tính năng E,
  • Tất cả các biến được chứa trong tính năng F,
  • Tất cả Chế độ xem (tùy chỉnh) được chứa trong tính năng G,
  • Tất cả các quy tắc (tùy chỉnh) được chứa trong tính năng H,
  • V.v.

Danh sách trên hầu như không giới hạn: cuối cùng, bạn thậm chí có thể nghĩ đó là 1 tính năng cho mỗi tùy chọn menu quản trị Drupal ... nếu bạn muốn đi xa đến vậy.

IMO nó cũng là cách tiếp cận được khuyến nghị nhất cho các tính năng gói.

3 - Giảm khả năng xảy ra xung đột trong Tính năng và / hoặc GIT

Không sử dụng lại các trường

Khá nhiều xung đột dường như được gây ra bởi việc sử dụng lại các trường giữa nhiều loại nội dung. Ví dụ: trong loại nội dung A, bạn có một trường có tên máy field_somefield, cũng được sử dụng làm trường trong loại nội dung B có cùng tên máy field_somefieldnhưng là loại trường khác và / hoặc một số cài đặt trường khác khác.

Bằng cách không sử dụng lại các trường giữa các loại nội dung, bạn tránh chạy trong vấn đề này. Hãy xem một quy ước đặt tên thú vị cho tên máy của các loại nội dung và trường của bạn như được hiển thị trong bảng Bao bì Kiến trúc và Tài liệu Thông tin , là một phần của các bài viết về " Mô hình tương đối cho Drupal ". Để biết thêm chi tiết về điều đó, hãy tham khảo câu trả lời của tôi về " Làm cách nào để mô hình hóa nội dung (các loại) theo quan điểm tập trung vào cơ sở dữ liệu? ".

Tính năng phân chia tùy thuộc vào người làm việc trên những gì

Nếu nhiều người đang làm việc trên một trang web, số lượng xung đột có thể được giảm bằng cách tổ chức (= tạo riêng biệt) các tính năng dựa trên ai đang làm việc trên cái gì. Một minh họa về điều này có thể như trong ví dụ này:

  • Lượt xem đi vào tính năng A,
  • Quy tắc đi vào tính năng B,
  • Biểu đồ đi trong tính năng C,
  • Bất cứ điều gì về Theming đều có trong tính năng D,

4 - Môi trường Drupal được đề xuất

Mọi thứ ở trên sẽ giúp phần nào tạo điều kiện thuận lợi cho việc sử dụng các Tính năng . Tuy nhiên, để đảm bảo mọi thứ sẽ hoạt động như mong đợi (được thiết kế), bạn cũng cần có một bộ môi trường thích hợp (các trang web Drupal liên quan đến logic) về cơ bản những lý do sau:

  • hợp nhất chức năng được cung cấp bởi nhiều tính năng.
  • dự đoán và giải quyết xung đột.
  • thử nghiệm của người dùng cuối về tất cả các tính năng được hợp nhất được chứng nhận để không có bất kỳ xung đột nào.

Trong thế giới lý tưởng, các trang web Drupal liên quan đến logic này phải được định cấu hình và sử dụng, như vậy:

  1. Trang web Dev cá nhân - mỗi nhà phát triển trang web có một trang dev riêng biệt. Khi một phần của sự phát triển đã sẵn sàng để được chia sẻ với người khác, một tính năng phù hợp sẽ được tạo ra, được chuyển đến môi trường dàn dựng.
  2. Trang web Sandbox - đây là môi trường Drupal chỉ chứa lõi Drupal, được sử dụng để kiểm tra tính hoàn chỉnh của một tính năng duy nhất. Nếu một tính năng, vô tình, có một số phụ thuộc không mong muốn (ví dụ: một số mô-đun mà tính năng này phụ thuộc vào, không được bật trong Hộp cát), thì đây là lúc sự phụ thuộc đó sẽ trở nên rõ ràng.
  3. Trang web dàn - đây là nơi một hoặc nhiều tính năng (được tạo trong một trang dev) được gửi đến. Nó có thể chỉ là một số hotfix cho một số vấn đề sản xuất, hoặc nó có thể là nơi tất cả sự phát triển cho một bản phát hành mới của trang web được hợp nhất. Nếu có bất kỳ xung đột nào giữa nhiều tính năng tồn tại, thì đây là môi trường nơi chúng sẽ xuất hiện đầu tiên ... và cần được giải quyết bằng cách nào đó.
  4. Trang web QA - sau khi môi trường Staging được coi là ổn định, đã đến lúc chuyển sang các tính năng có liên quan và cung cấp chúng ở cấp độ cao hơn để sử dụng chúng để kiểm tra QA, kiểm tra chấp nhận, kiểm tra âm lượng, v.v. Ở cấp độ này, bạn phải cực kỳ cẩn thận trong việc cho phép bất kỳ thay đổi bổ sung (nếu có). Bởi vì bất kỳ thay đổi nào như vậy có thể làm mất hiệu lực tất cả các nỗ lực thử nghiệm trước đó đã hoàn thành trong môi trường này.
  5. Trang web sản xuất bóng - Để chuẩn bị kích hoạt trong sản xuất thực, trước tiên bạn có thể muốn quảng bá thêm các tính năng có liên quan đến một môi trường được coi là bản sao (bóng) của môi trường sản xuất thực của bạn. Nếu tại thời điểm này trong quá trình di chuyển, mọi thứ vẫn bị hỏng, thì đó là cờ đỏ để hoàn nguyên một số bước trước đó của bạn. Hãy sửa nó và thử lại, cho đến khi tất cả các bên liên quan chấp thuận các thay đổi.
  6. (Các) Trang web sản xuất - Nếu bạn đã hoàn thành tất cả các bước trước đó, thì bước này sẽ tự giải thích và khá dễ dàng. Tùy thuộc vào nhu cầu của bạn, đây có thể là một trang web hoặc một cái gì đó tương đương với Nhiều trang web của Drupal trong khi tất cả các trang web có liên quan đều chạy các phiên bản giống nhau của tất cả các tính năng.
  7. Trang web cơ bản - Theo kinh nghiệm của tôi, không có nhiều (nếu có) tất cả các triển khai Drupal nơi loại trang web này được sử dụng (cũng). Nó chỉ đơn giản là một bản sao của (các) Trang web sản xuất, nhưng có sẵn cho các nhà phát triển, người thử nghiệm Drupal, v.v. có thể được sử dụng để xác minh xem các trang web sản xuất trông như thế nào, hoặc để thực hiện đào tạo người dùng, v.v. chu kỳ được bắt đầu, các thành phần của một trang web sẽ bị ảnh hưởng (cần phải thay đổi) nên được "sao chép bằng cách nào đó" bằng cách sử dụng Trang web cơ sở này làm đầu vào, với mục tiêu là Trang web phát triển cá nhân .

Rõ ràng, hàng tồn kho ở trên của các loại trang web Drupal giống như thế giới lý tưởng. Tùy thuộc vào quy mô của nhóm phát triển của bạn và / hoặc ngân sách có sẵn để tạo và duy trì chúng, không phải tất cả chúng đều có thể được sử dụng (hoặc giá cả phải chăng). Khoảng không quảng cáo này được mô hình hóa sau các hoạt động tốt nhất trong lĩnh vực SCM, được sử dụng trong hầu hết các tập đoàn lớn / toàn cầu (ngân hàng, hãng hàng không, v.v.).

5 - Các mô-đun liên quan

Mạnh mẽ

Các StrongARM mô-đun cho phép xuất khẩu các biến (các module mà lưu trữ các thiết lập của họ trong các biến) với tính năng mô-đun.

Xuất khẩu nút

Các xuất khẩu Node mô-đun cho phép người dùng các nút xuất khẩu và sau đó nhập vào một cài đặt Drupal.

Vai trò xuất khẩu

Các Vai trò xuất khẩu mô-đun cho phép vai trò có machine_names và tạo ra một vai trò id duy nhất (loại bỏ) dựa tắt của machine_name. Vai trò có thể được xuất với Tính năng và được loại bỏ chính xác nếu được nhập trên các trang web khác.

Tính năng Banish

Các tính năng Banish mô-đun cho phép để loại trừ hoàn toàn các tính năng cá nhân các thành phần từ các tính năng giao diện người dùng và các tính năng xuất khẩu. Đây là một trích dẫn về nó từ trang dự án của nó:

 Mô-đun này hữu ích khi có các thành phần tính năng mà bạn muốn đảm bảo KHÔNG BAO GIỜ được xuất. Nếu bạn đang sử dụng các tính năng để xây dựng hoặc triển khai trang web thì có lẽ bạn đã gặp phải vấn đề ai đó vô tình xuất các biến dấu thời gian như cron_last hoặc update_last_check. Bạn cũng có thể muốn loại bỏ các quyền đối với các mô-đun dành cho nhà phát triển để họ không bị cuốn theo phần còn lại của các quyền mà bạn muốn xuất. Các mục bị trục xuất sẽ không hiển thị trong mô-đun tính năng của bạn HOẶC BẤT K MOD TÍNH NĂNG NÀO KHÁC, vì vậy hãy thận trọng khi sử dụng. Để biết danh sách trung tâm các tính năng không bao giờ được xuất, hãy xem https://www.drupal.org/node/2400531

HẠT ĐẬU

Các Bean mô-đun làm cho khối của bạn có thể xuất khẩu. Đây là một trích dẫn về nó từ trang dự án của nó:

Hãy nghĩ về Bean như một phương pháp để cung cấp các loại mới (so với nút này sẽ là một loại nội dung) sau đó cung cấp giao diện thêm nội dung để tạo nhiều khối như bạn yêu cầu (xem ảnh chụp màn hình bên dưới). Nội dung bean sau đó có thể được đặt xung quanh trang web giống như bất kỳ khối nào khác.

Module này cũng hoạt động tuyệt vời khi kết hợp với các UUIDtính năng UUID tích hợp mô-đun. Mô-đun này chỉ bắt đầu từ D7, nhưng nó đã được bao gồm trong lõi 8 Drupal. Video hướng dẫn mô-đun Drupal Bean - sử dụng Bean Admin UI cung cấp một giới thiệu tuyệt vời để thực sự hiểu sức mạnh của mô-đun này và loại điều bạn có thể làm với nó (chỉ bằng cách sử dụng các kỹ thuật xây dựng trang web, không có mã hóa tùy chỉnh liên quan).

Môi trường sống

Các Habitat mô-đun có ý nghĩa nhất trong một tính năng workflow dựa trên. Đây là một trích dẫn về nó từ trang dự án của nó:

Trong thiết lập đa môi trường (ví dụ: prod, test, dev, local), có một số mô-đun mà bạn muốn luôn được bật hoặc tắt trên một số môi trường nhất định. Mỗi lần bạn đồng bộ hóa cơ sở dữ liệu mặc dù bạn phải bật lại / vô hiệu hóa các mô-đun tương tự. Tồi tệ hơn, bạn trở nên lười biếng và tiếp tục kích hoạt các mô-đun phát triển.

Môi trường sống cung cấp các cài đặt để bật hoặc tắt các mô-đun nhất định trên từng môi trường (môi trường sống). Chỉ cần đặt một biến với ví dụ $ conf ['habat'] = 'local'; trong tệp settings.php của bạn (biến thực tế để sử dụng có thể định cấu hình cho quy trình làm việc hiện tại của bạn). Các mô-đun vô hiệu hóa / kích hoạt được thực hiện trên hook_init.

6 - Tài nguyên được đề xuất:

7 - Các lựa chọn thay thế có thể cho việc sử dụng Tính năng

Nếu bạn không thể, hoặc sẵn sàng (chưa), sử dụng Tính năng , thì bạn có thể muốn kiểm tra xem những gì mở rộng các phương pháp / mô-đun bên dưới có thể cung cấp một số loại thay thế.

Xuất / nhập thủ công

Đây là các tiện ích thường được biết đến (để tránh các tính năng từ ...) có sẵn thông qua giao diện người dùng quản trị viên, cho các mô-đun như Quy tắc , Chế độ xem , v.v (danh sách không đầy đủ!).

Bản sao gói

Một số người coi mô-đun sao chép Bundle như một sự thay thế có thể. Nó có hỗ trợ xuất / nhập cho:

  • Các loại nút.
  • Phân loại học.
  • Người sử dụng.
  • Các trường API trường.
  • Nhóm lĩnh vực.

1
Câu trả lời hay nhất tôi từng thấy.
Không có Sssweat

@NoSssweat Merci cho kudos ... nhưng biết rằng tôi coi nó vẫn còn chưa hoàn thiện. Ví dụ, nó hầu như không bao gồm bất cứ điều gì về "vòng đời" của các tính năng xử lý và nó chưa nói nhiều về những thứ như phân tích tác động, kiểm toán, quản lý phát hành, ủy quyền và, và (hàng tá chủ đề khác).
Pierre.Vriens

1
@ Pierre.Vriens - Cảm ơn! Tôi đoán tôi đã đi đến kết luận giống như câu trả lời xuất sắc của bạn một cách khó khăn. Tôi đã thử cách tiếp cận phân tách theo các thành phần (lượt xem, lượt xem, phụ thuộc, v.v.) nhưng đã gặp xung đột khi cố gắng tạo tính năng. Tôi nhận ra -> sau -> rằng tôi có thể cần phải định cấu hình tính năng để không kiểm tra phụ thuộc và bỏ qua xung đột.
stefgosselin

7

Xung đột hợp nhất có thể sẽ được đưa ra khi nhiều nhà phát triển đang tích hợp cấu hình của họ vào Tính năng. Tôi đã viết lên một số hướng dẫn để xem lại mã tính năng, nhưng tôi nghĩ quan trọng nhất là:

Chỉ cam kết thay đổi mã dự định.

Điều đó có nghĩa là gì? Điều này có nghĩa là mỗi nhà phát triển phải xem lại mã trước khi cam kết. Không có "phép thuật" nào để ngăn chặn những thay đổi mã ngoài ý muốn mà không có nhà phát triển thận trọng.

  • Xem lại thay đổi mã với git diff.
  • Tạo một bản vá khác biệt nhanh bằng cách sử dụng git diff > blah.patchvà sửa đổi thủ công bản vá để chỉ bao gồm các thay đổi cấu hình dự định.
    • Những thứ như "mtime", các bình luận trong chế độ xem xuất khẩu trong tệp thông tin không cần phải được đưa vào cam kết.
    • Tôi đã trở nên khá thành thạo trong việc xem xét các khối mã cấu hình khác nhau theo thời gian. Bây giờ dễ dàng hơn để phát hiện những thay đổi không cần thiết trong chế độ xem hoặc bảng điều khiển và 10ddvim nhanh chóng thoát khỏi sự thay đổi trong một bản vá (ví dụ).
    • Tôi nghĩ "Ồ, này, tôi đã không thay đổi bất cứ điều gì để làm với các lĩnh vực, vì vậy tôi sẽ không cam kết featurename.features.field_base.inc."
  • Không bao giờ sử dụng git commit -a. Đây là một thực tế khủng khiếp nên được sử dụng. Luôn luôn thêm và cam kết rõ ràng!
  • Sử dụng git rebasetrên các nhánh git cục bộ để đảm bảo tính năng này được cập nhật nhất.
  • Chiến lược hợp nhất git cũng có thể giúp ích khi thực sự hợp nhất:
    • git merge -s recursive -X patience (yêu cầu git 1.7+ iirc).

Cuối cùng hãy xem xét thêm các hạn chế xã hội cho các nhà phát triển để nhà phát triển phải xem xét mã của họ trước khi hợp nhất vào thân cây / ổn định với đánh giá bản vá hoặc yêu cầu kéo. Mọi người sẽ tức giận về các hạn chế xã hội, nhưng họ nên tức giận vì đã không xem lại mã của họ.


Tốt hơn là tạo một tệp vá đang sử dụng git add -pđể chỉ cam kết các khối cụ thể.
donquixote
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.