Điểm:0

Làm cách nào để xử lý các thay đổi cấu hình trong prod và bởi nhiều nhà phát triển?

lá cờ cn

Tôi có hai tình huống trong quản lý cấu hình mà tôi không chắc chắn về cách xử lý:

  1. Người dùng lập dị thực hiện thay đổi cấu hình trong quá trình sản xuất. Phương pháp hay nhất để nhập những thay đổi này vào nhà phát triển mà không phá hủy công việc đang được thực hiện trong nhà phát triển là gì? kéo gitdrush cim sẽ ghi đè mọi thứ bạn đang làm trong dev. tôi biết có drush cim --partial, nhưng theo những gì tôi hiểu thì đây không phải là cách làm được khuyến nghị (Nguồn). Tôi cũng có thể sử dụng mô-đun chỉ đọc cấu hình trong prod để tránh thay đổi cấu hình, nhưng có một số ví dụ mà người dùng thực sự được phép thay đổi cấu hình.

  2. Hai nhà phát triển làm việc trong môi trường nhà phát triển cục bộ của họ: Làm cách nào để đảm bảo một người không ghi đè công việc của người kia khi được đẩy lên giai đoạn hoặc sản xuất, đặc biệt khi cũng có những thay đổi về cấu hình trong sản xuất (xem 1)? Có lẽ một số cách phân nhánh git có thể hữu ích, nhưng tôi có thể sử dụng thêm một số trợ giúp về cách sử dụng chính xác.

Điểm:4
lá cờ us

Việc sử dụng tốt phân nhánh git chắc chắn có thể giúp ích cho việc này. Điều quan trọng là mỗi nhánh riêng lẻ có cơ sở cấu hình ổn định: không có gì bên ngoài nhánh có thể thay đổi trạng thái cấu hình bên trong nhánh, để sau này khi đến lúc xuất cấu hình trong nhánh và hợp nhất nó vào sản xuất, chỉ những thay đổi có liên quan đến chi nhánh được ghi lại.

Một cách để làm điều này là có một nhánh chính gọi là sản lượngvà HEAD của nhánh đó luôn theo dõi trạng thái sản xuất hiện tại của cơ sở mã của bạn. Tất cả các bạn đồng ý không cam kết hoặc hợp nhất mọi thứ với sản lượng trừ khi bạn đang chuẩn bị phát hành trực tiếp những nội dung đó.

Khi Arjun muốn làm việc trên một tính năng mới, họ tạo một nhánh mới từ sản lượng, và họ gọi nó là arjun-1.

Ngày hôm sau, Beth cần sửa một lỗi nên cô ấy đã mở chi nhánh mới của riêng mình sản lượng gọi điện beth-1.

Trong khi đó, người quản lý nội dung Ceci đang xây dựng biểu mẫu web trên giao diện người dùng của trang web, điều đó có nghĩa là cô ấy đang thực hiện các thay đổi cấu hình trực tiếp khác với trạng thái cấu hình của sản lượng. Theo một cách nào đó, cô ấy cũng đang tách ra khỏi sản lượng! Trên thực tế, hãy tiếp tục và tạo một ceci-1 chi nhánh của sản lượng now để đại diện cho điều này, mặc dù chúng tôi có thể sẽ chưa cam kết bất cứ điều gì với nó.

Vài ngày sau, các chi nhánh tương ứng của Arjun và Beth đã được xem xét và chấp nhận, đồng thời ban quản lý muốn triển khai một bản phát hành mới cùng với công việc của họ lên trang web trực tiếp.

Điều đầu tiên cần làm là kiểm tra ceci-1 nhánh, xuất cấu hình trực tiếp và gửi các tệp cấu hình đã cập nhật tới ceci-1.

Bây giờ bạn có thể tiến hành hợp nhất thành sản lượng: tính năng mới arjun-1, bản sửa lỗi beth-1và cập nhật cấu hình trực tiếp ceci-1. Có thể có xung đột hợp nhất để xem xét, nhưng bạn không cần phải lo lắng về việc vô tình ghi đè lên cấu hình của người khác. Điều này là do mỗi nhánh riêng lẻ có cơ sở nhất quán để xuất các thay đổi cấu hình riêng lẻ của riêng chúng.

Giả sử bạn đã không thực hiện một ceci-1 chi nhánh. Thay vào đó, bạn đã hợp nhất arjun-1beth-1 vào trong sản lượng, sau đó xuất cấu hình trực tiếp và đưa các bản cập nhật trực tiếp vào sản lượng. Bạn đã hơi say lên! Bạn đã thay đổi cơ sở cho các thay đổi cấu hình trang web trực tiếp của Ceci. Chúng dựa trên tình trạng sản xuất không có chi nhánh của Arjun và Beth. Việc xuất bây giờ sẽ ghi đè lên bất kỳ thay đổi cấu hình nào họ đã thực hiện.

Extect avatar
lá cờ cn
Cảm ơn bạn rất nhiều vì đã trả lời chi tiết !!!
Điểm:0
lá cờ de

Thay đổi không bao giờ nên được thực hiện trong sản xuất. Thay đổi cấu hình sản xuất nên được thực hiện cục bộ bởi các nhà phát triển. Xung đột hợp nhất nên được sắp xếp trên máy cục bộ của họ. Vì vậy, nó sẽ diễn ra như thế này:

  1. Nhà phát triển kiểm tra mã
  2. Nhà phát triển thực hiện các thay đổi xuất cấu hình
  3. Nhà phát triển cố gắng đẩy, bị từ chối để thực hiện các cam kết mới
  4. Nhà phát triển kéo, xem các thay đổi trong cấu hình
  5. Nhà phát triển nhập cấu hình mới để đảm bảo cấu hình được nhập đúng cách và những thay đổi trong cam kết của anh ấy không bị gián đoạn
  6. Nhà phát triển xuất cấu hình sau khi thực hiện bất kỳ sửa chữa, cam kết và đẩy tới máy chủ

Mọi thay đổi đối với cấu hình được thực hiện trực tiếp trên các máy chủ từ xa sẽ được ghi đè sau mỗi lần đẩy. Điều này giải quyết các vấn đề trên của bạn, ngoại trừ có thể:

có một số ví dụ mà người dùng thực sự nên được phép để thay đổi cấu hình.

Chẳng hạn như?

Les Lim avatar
lá cờ us
Chẳng hạn như: thêm hoặc định cấu hình biểu mẫu web, sắp xếp lại các khối, thêm vai trò người dùng, điều chỉnh quy trình công việc, thay đổi hình ảnh mặc định của trường hình ảnh, v.v. Chắc chắn, thật tuyệt nếu tất cả điều này có thể xảy ra trong môi trường nhà phát triển được kiểm soát, nhưng hầu hết các trang web Drupal không có nhóm nhà phát triển có thể kiểm soát tất cả những thay đổi đó thông qua quy trình triển khai.
Extect avatar
lá cờ cn
Cảm ơn @Les Lim! Đây chính xác là những trường hợp sử dụng mà tôi muốn nói. Một số dự án cần linh hoạt hơn hoặc dự án quá nhỏ nên không có nhóm nhà phát triển nào luôn sẵn sàng thực hiện các thay đổi trong môi trường nhà phát triển được kiểm soát. Trong cả hai trường hợp, có nhiều thay đổi hơn đang được thực hiện trong prod và đây chính xác là vấn đề khiến tôi bối rối không biết quy trình làm việc tốt nhất sẽ như thế nào (nếu có).
Jaypan avatar
lá cờ de
Cá nhân tôi có một sự phân biệt với các khách hàng rằng các thay đổi cấu hình như trên là xây dựng trang web, không phải quản lý nội dung. Tôi không thấy các trường hợp mà khách hàng nên thêm vai trò người dùng, thay đổi quy trình làm việc và thay đổi hình ảnh mặc định trên các trường. Chúng tôi xây dựng trang web cho khách hàng sử dụng, mở ra việc xây dựng trang web cho khách hàng sẽ mở ra các vấn đề - chẳng hạn như vấn đề này!
Jaypan avatar
lá cờ de
Tôi nên nói thêm, trình tạo bố cục có thể được sử dụng để giải quyết vấn đề với các khối. Biểu mẫu web là vấn đề lớn nhất mà tôi thấy đối với bạn. Mặc dù vậy, tôi không sử dụng nó vì nó chỉ mở ra các vấn đề theo kinh nghiệm của tôi. Ngoại lệ mà tôi muốn sử dụng nó sẽ là nơi yêu cầu của dự án là khách hàng có thể xây dựng các biểu mẫu của riêng họ.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.