Quy trình công việc được đề xuất cho cấu hình di chuyển (CMI) từ dev -> giai đoạn -> sản xuất là gì?

41

Chúng tôi đã có một drupalcamp vài tháng trước và có người hỏi về việc quản lý triển khai với hệ thống cấu hình mới (CMI). Một quy trình làm việc lý tưởng có thể sẽ liên quan đến việc giữ cấu hình trong kiểm soát phiên bản và vẫn có thể di chuyển cấu hình giữa các thành viên trong nhóm.

Điều tốt nhất mà chúng tôi trong phòng có thể tìm ra (một phần dựa trên bài thuyết trình tại DrupalCon Portland) là:

Yêu cầu kiểm soát phiên bản để bỏ qua thư mục cấu hình hoạt động.
Sao chép tất cả Cấu hình qua thư mục dàn và cam kết kiểm soát phiên bản.

Và sử dụng settings.php để đảo ngược thư mục hoạt động / dàn giữa 2 môi trường. Tuy nhiên, trong khi tìm ra một quy trình triển khai từ một máy chủ sang máy chủ tiếp theo thì phức tạp nhưng có thể thực hiện được, luồng công việc được đề xuất từ nhiều môi trường cục bộ (tức là nhiều nhà phát triển) vào dev (hoặc giữa nhau) - Một vấn đề có thể xảy ra là mọi thành viên trong nhóm sẽ chia sẻ cùng một môi trường tương tự hoặc tương tự, vậy làm thế nào để thay đổi trên máy của một đồng đội?

migration 8 version-control

— btmash
nguồn

5

Tôi không thực sự đồng ý với số phiếu gần hiện tại. Vì CMI là trọng tâm của Drupal 8, tôi nghĩ chúng ta có thể có một số câu trả lời tốt ở đây.

— mpdon Arena

3

Đồng ý, đây là câu hỏi rất hay. Tôi tin rằng nhiệm vụ quan trọng drupal.org/node/1703168 là về vấn đề này và các chủ đề khác và vẫn chưa được giải quyết hoàn toàn, vì vậy một câu trả lời ở đây có thể giúp đẩy vấn đề đó về phía trước.

— Berdir

Tôi xin lỗi nếu câu hỏi của tôi bị đưa ra là tiêu cực đối với sáng kiến CMI (hoàn toàn không phải là ý định của tôi). Tôi đã cập nhật câu hỏi để nó có vẻ trung tính hơn.

— btmash

2

tôi gần như sẽ nói "Bạn đã thử tính năng" chưa. Có lẽ "D8" nên đi trong tiêu đề câu hỏi? Thẻ "8" là một chút vô hình.

— donquixote

1

Sửa đổi tiêu đề để câu hỏi có thể được nhìn thấy bằng thẻ hoặc thông qua tiêu đề :)

— btmash

19

Sau khi nói chuyện một chút với những người duy trì CMI, cuộc thảo luận về cách tiếp cận tốt nhất vẫn chưa kết thúc nhưng sau đây là điều có ý nghĩa nhất vào lúc này.

Cố gắng giữ nó thật ngắn gọn, sẽ cố gắng mở rộng dựa trên các câu hỏi / khi vấn đề được tham chiếu được giải quyết bằng một câu trả lời chính thức.

Vì vậy, đầu tiên, sự thật ...

Như đã đề cập, có thư mục hoạt động và dàn dựng. Hoạt động được Drupal quản lý hoàn toàn, thực hiện các thay đổi trực tiếp trong đó (trực tiếp hoặc gián tiếp bằng cách chuyển sang một vị trí khác) không được hỗ trợ.
Dàn dựng là nơi Drupal tìm kiếm cấu hình để nhập và doe nếu không quan tâm đến nó.
Quá trình nhập là quan trọng, thay đổi cấu hình có thể ảnh hưởng đến một trang web theo một cách nhất định và cần được kiểm tra tính hợp lệ. Ví dụ, bạn không thể thay đổi loại trường của trường văn bản thành tham chiếu thực thể, điều đó không hoạt động.
Quá trình nhập cấu hình luôn cần chạy trên tất cả các cấu hình, bạn không thể nhập một chế độ xem hoặc loại nút duy nhất. Nó đã được thử, nhưng cố gắng đối phó với sự phụ thuộc, loại bỏ / đổi tên và do đó dẫn đến một hệ thống rất phức tạp và nó không hoạt động.
Cách duy nhất để cài đặt lại cấu hình mặc định, là cài đặt lại mô-đun đó. Điều đó có nghĩa là trước tiên nó sẽ cố gắng loại bỏ tất cả cấu hình (như các trường). Vì vậy, đó không thực sự là một lựa chọn. Tôi nghĩ rằng những thay đổi cụ thể trong các chức năng cập nhật nhưng quá tẻ nhạt đối với điều này.
Như mô-đun tính năng mô tả, nó sẽ tập trung vào việc cung cấp chức năng có thể sử dụng lại, chứ không phải triển khai cấu hình liên tục. Đây là những gì nó được thiết kế cho ở nơi đầu tiên.

Do đó, khuyến nghị ngay bây giờ là đưa thư mục dàn vào kiểm soát phiên bản. Mỗi nhà phát triển sau đó có toàn quyền kiểm soát những gì anh ta đặt ở đó, bằng cách sao chép toàn bộ thư mục hoạt động hoặc chỉ một tệp cấu hình cụ thể. Các thay đổi thư mục dàn dựng sau đó được cam kết, được đẩy sang sản xuất và nhập cấu hình được chạy (trong UI hoặc với drush).

— Berdir
nguồn

Thư mục dàn trong kiểm soát phiên bản, tôi nhận được phần đó. Các phần khác là những gì tâm trí của tôi đang cố gắng xử lý. Vì vậy, nếu ai đó thực hiện thay đổi, họ sao chép các thay đổi của họ vào thư mục dàn dựng và cam kết. Sau thời điểm đó, các nhà phát triển / máy chủ tiếp theo sẽ nhận được các thay đổi và đồng bộ hóa các thay đổi của họ đối với thư mục hoạt động. Và rửa và lặp lại cho bất kỳ chuỗi máy chủ nào khác trên đường đi (dàn dựng, sản xuất, v.v.). Và nó luôn luôn đi qua giai đoạn để không có chuyển đổi thư mục xảy ra nữa. Điều đó có chính xác không?

— btmash

Đúng. Không có chuyển đổi thư mục. Mọi thay đổi cấu hình phải trải qua quá trình nhập hoặc bạn có thể kết thúc với trang bị hỏng. Ví dụ, danh sách các mô-đun cũng là cấu hình. Triển khai nó có nghĩa là các mô-đun cần phải được cài đặt / gỡ cài đặt (Lưu ý: Điều này chưa hoạt động, nhưng có một vấn đề cần khắc phục).

— Berdir

Ok, vì vậy thậm chí nhiều câu hỏi hơn bây giờ (chia thành 2 bình luận) :) Đầu tiên, bạn đề cập đến các mô-đun là cấu hình. Vì vậy, ngay cả khi một mô-đun được thêm vào repo và không được bật / tắt, nó cần phải được cài đặt / gỡ cài đặt chỉ để ngồi ở đó?

— btmash

Và theo dõi: (A) Sẽ có cơ chế sao chép các thay đổi từ thư mục hoạt động -> dàn dựng (để đơn giản hóa so với một người đi vào thư mục cấu hình cho các thành phần này - có thể là một cách để chọn các biến nhất định). (B) Thư mục dàn có bị xóa sau khi các thay đổi được đồng bộ hóa từ dàn không -> hoạt động? (B1) Nếu vậy, chiến lược từ quan điểm devops để thiết lập lại thư mục đó trước khi kéo git? (B2) Nếu không, thì có đúng không khi cho rằng trong khi dàn dựng-> đồng bộ hóa hoạt động xảy ra, không nên có bất kỳ ảnh hưởng nào đến cấu hình không thay đổi?

— btmash

Trạng thái cài đặt mô-đun là cấu hình. Không phải bản thân mô-đun :) Đó là những gì bạn triển khai. a) Có một giao diện người dùng để tải xuống tar.gz của thư mục hoạt động, một giao diện để tải tar.gz vào thư mục dàn và một để thực sự Nhập, với tổng quan và khác biệt về các thay đổi. B) Tôi tin ngay bây giờ nó đã bị xóa, nhưng tôi cho rằng bạn có thể dễ dàng hoàn nguyên điều đó với git. Không chắc chắn, dễ kiểm tra. Tất cả những thứ đó đều có thể cắm được, vì vậy có thể có một cách thực hiện hơi khác mà không xóa. B2) Tôi không nhận được cái này nhưng tôi nghĩ là có.

— Berdir

4

Tuyệt vời trả lời cho đến nay. Cảm ơn tất cả các bạn!

Chúng tôi đã bắt đầu một dự án Drupal 8 gần đây và thực hiện quy trình làm việc sau đây.

Chúng tôi có ba thư mục hoạt động, dàn dựng và xuất khẩu. Các nhà phát triển đổ của họ để xuất khẩu. Tôi không muốn giữ nó trong giai đoạn. Tôi nghĩ rằng nó dễ dàng hơn để làm việc khi cấu hình chia sẻ không được lưu trữ trực tiếp trong thư mục dàn. Nó chỉ là một câu chuyện giả vờ mà tôi không có sự thật phũ phàng nào về điều này ...

Mẫu dự án drupal 8 hiện tại của chúng tôi có sẵn trên github. Tôi cũng đã viết một số lệnh drush tiện dụng để tăng tốc độ dòng chảy của devleoper. Không cần sao chép thủ công từ hoạt động để xuất khẩu.

Mẫu dự án: https://github.com/webflo/d8-project-template
Các lệnh Drush bổ sung: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
nguồn

1

Cho đến nay, tôi đồng ý với phương pháp này. Tôi đã thêm tất cả các tính năng từ các liên kết trong bài đăng này vào các lệnh config-export và config-import của Drush. Tôi hy vọng những người khác sẽ cùng tôi và @florian khám phá giải pháp 3 thư mục này.

— moshe weitzman

Làm thế nào để bạn đối phó với sites/default/files/config_HASHthư mục cấu hình có hậu tố băm, ví dụ: config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— trị liệu

@therobyouledge Có thể ghi đè vị trí của các thư mục này. Chỉ cần tìm "Vị trí của tệp cấu hình trang web." trong settings.php Tôi sử dụng đoạn mã sau. Điều này có nghĩa, cấu hình được lưu trữ bên ngoài thư mục gốc Drupals. $ config_directories = mảng ('active' => '../config/active', 'staging' => '../config/staging',);

— webflo

Cảm ơn @webflo tôi đã thấy điều này. Điều gì sẽ là lợi ích của việc quản lý một cơ sở mã và một cấu hình riêng biệt? Tôi nghĩ rằng sự tách biệt này là một chút giả tạo vì cả mã và cấu hình (trong yaml) xác định hành vi và phụ thuộc lẫn nhau. Trong Drupal 7, mã cấu hình (hoặc có thể theo dõi bởi Git) đã được thực hiện với mô-đun Tính năng tạo mô-đun cho từng cấu hình cụ thể được yêu cầu theo dõi trong mã. Trong Drupal 8, có các Tính năng 3.x mà theo tôi hiểu, nó cũng tương tự nhưng sử dụng YAML để lưu cấu hình và các mô-đun được tạo không phụ thuộc vào mô-đun Tính năng.

— trị liệu

Tôi nghĩ rằng bạn đã hiểu nhầm tôi, cấu hình dir vẫn còn trong git, nhưng trang web Drupal của tôi không nằm trong root git repo. Các trang web được lưu trữ / web. Vì vậy, / config và / web ở cùng cấp độ.

— webflo

2

Tôi chưa thử điều này, nhưng kế hoạch của tôi là tạo ra một mô-đun tùy chỉnh chứa các tệp cấu hình "mặc định" chỉ chứa cấu hình tôi quan tâm. Tôi tin rằng các mô-đun khác có thể chứa các cấu hình ghi đè các mô-đun khác. (Nếu không điều này nên được thực hiện).

Tôi nghĩ bạn phải để thư mục cấu hình một mình. Lờ nó. Nó được tạo tự động khi cài đặt từ tất cả các tệp cấu hình của các mô-đun riêng lẻ. Con đường dài và ngẫu nhiên. Nếu bạn giữ tất cả số đó trong một repo, bạn sẽ cần một repo riêng và bạn sẽ mang theo hàng tấn tệp cấu hình mặc định, không cần thiết.

Đặt cấu hình trong một mô-đun tùy chỉnh làm cho nó trở thành một phần của cơ sở mã chính của bạn.

Quá trình triển khai sẽ là:

Git kéo hoặc bất cứ điều gì để có được các tập tin mới.
Xóa bộ nhớ cache.
Đặt lại cấu hình mặc định. (Từ tệp của mô-đun tùy chỉnh của bạn)

Bạn có thể tạo các mô-đun tùy chỉnh (với cấu hình riêng) cho từng môi trường nếu bạn muốn.

— jonpugh
nguồn

Điều này nghe có vẻ rất nhiều như các tính năng, phải không? Hoặc có một sự khác biệt đáng kể mà tôi đang thiếu?

— Letharion

Đó là một cách tiếp cận thú vị và tôi thích ý tưởng này. Tuy nhiên, một trong những lợi thế lớn nhất đã được đề cập như một phần của sáng kiến CMI là khả năng di chuyển qua cấu hình từ các thư mục cấu hình. Và từ những gì tôi thấy, tệp settings.php cho phép bạn xác định vị trí của các thư mục đang hoạt động / sắp xếp (ví dụ: chúng không cần phải là các đường dẫn được tạo tự động). Do đó, tôi nghĩ rằng một quy trình làm việc với cấu hình hiện tại là có thể mà không cần phải tạo một tính năng như @Letharion đề cập ở trên.

— btmash

2

Lưu ý: Tôi đánh giá cao rằng đây không phải là câu trả lời theo nghĩa chặt chẽ nhất liên quan đến câu hỏi, nhưng dù sao tôi cũng đã đặt nó ở đây và tôi sẽ xem lại và chỉnh sửa / xóa khi Tính năng có bản phát hành 8.x và bụi đã giải quyết thêm một chút. Điều này quá lớn cho một bình luận và tôi muốn nhận 0,02 bảng của mình trong :-)

Là một fan hâm mộ lớn của các Tính năng , tôi khuyên bạn nên để mắt đến hóa thân D8 của mô-đun Tính năng .

Lấy từ trang dự án

Phiên bản 3.x của Tính năng được lên kế hoạch cho Drupal 8 để tích hợp với hệ thống quản lý cấu hình mới. Nếu bạn chỉ cần xuất cấu hình trang web đơn giản, nên sử dụng hệ thống quản lý cấu hình D8 thay vì Tính năng. Bạn sẽ sử dụng các Tính năng trong D8 để xuất chức năng đi kèm (như "tính năng thư viện ảnh").

Con đường tôi kinda nhìn thấy nó là ý tưởng này làm cho nó dễ dàng hơn cho dev đội để làm việc trên các bộ phận nhỏ của một trang web. Tôi sẽ không đi vào quy trình công việc mặc dù vẫn còn quá nhiều biến số chưa biết, nhưng tôi không thể thấy nó khác nhiều so với quy trình triển khai Tính năng hiện tại.

Tôi không thể giúp nhưng nghĩ có, CMI thật tuyệt vời; nhưng hầu hết các trang web của tôi vẫn sẽ kết thúc với các mô-đun Tính năng (mặc dù số lượng nhỏ hơn do không phải xuất MỌI loại nội dung, quyền, v.v.)

— Chapabu
nguồn

Mặc dù tôi đồng ý rằng các tính năng sẽ thay đổi một chút vai trò của nó và (hy vọng) là công cụ để kết hợp các thành phần cấu hình lại với nhau (như tính năng thư viện ảnh mà bạn đề cập), cấu hình (theo như tôi hiểu) vẫn sẽ được duy trì thông qua hoạt động thư mục cấu hình. Vì vậy, Tính năng có thể giải quyết một thành phần nhất định nhưng cách quản lý dòng công việc cấu hình được quản lý trên các môi trường là vấn đề thực sự. Quy trình triển khai hơi khác so với quy trình triển khai các tính năng hiện tại chủ yếu vì dữ liệu kích hoạt nằm trong db và kho dữ liệu là các tệp.

— btmash

... Quy trình triển khai tính năng d7 liên quan đến dữ liệu kích hoạt trong cơ sở dữ liệu và kho dữ liệu trong tệp. Chúng tôi đang chuyển sang cả hai tập tin và chỉ cần đảm bảo rằng điều đó ảnh hưởng đến sự thay đổi trong quy trình làm việc.

— btmash

Lưu ý rằng các tính năng thực sự không có khái niệm hoạt động và kho dữ liệu / dàn. Hoặc ít nhất là không nhất quán, tất cả phụ thuộc vào móc / vật cụ thể mà nó tích hợp. Các chế độ xem mặc định trực tiếp trong mã, ví dụ: các thay đổi được kích hoạt ngay lập tức (ngoài bộ đệm), không có quy trình triển khai được kiểm soát với các tính năng. Đó luôn là một trong những vấn đề lớn khi sử dụng các tính năng để triển khai.

— Berdir

Bạn đúng. Tôi không biết làm thế nào tôi có mô-đun cấu hình cho D7 trộn lẫn với Tính năng nhưng tôi đã làm.

— btmash