Khi nào thì thích hợp để bắt đầu sử dụng phiên bản tiếp theo của một công cụ khi dogfooding?

Cụ thể, tôi đang làm việc trên một công cụ tích hợp DVCS và hệ thống xây dựng, nhưng tôi hình dung thách thức mà tôi gặp phải sẽ phát sinh đối với bất kỳ ai phát triển công cụ "meta" (trình biên dịch, VCS, xây dựng hệ thống, chạy thử, v.v.) muốn phát triển thông qua "dogfooding" .

Câu hỏi của tôi là: trong quy trình phát hành kiểu scrum bằng cách sử dụng quy trình phân nhánh , tôi bắt đầu sử dụng phiên bản mới hơn của công cụ nào trong chu kỳ phát triển của công cụ?

Tôi đang tìm kiếm một quá trình để tạo sự cân bằng giữa:

• liên tục sử dụng developphiên bản của công cụ: Tôi thấy tôi đang phá vỡ sự phát triển của chính mình khi những thay đổi được kết hợp.

• liên tục sử dụng masterphiên bản của công cụ: bất kỳ vấn đề nào tôi phát hiện ra thông qua dogfooding là những vấn đề đã được phát hành.

Điều đầu tiên cần làm là kiểm tra hồi quy ngoại tuyến tự động rất kỹ lưỡng. Làm cho việc vượt qua các bài kiểm tra đó là một yêu cầu tối thiểu cho những gì bạn chính thức sử dụng.

Thứ hai, bạn cần một cách đơn giản để quay lại phiên bản làm việc trước đó, cho các vấn đề mà các bài kiểm tra tự động của bạn không nắm bắt được.

Ví dụ, nhân Linux của tôi đã được vá tùy chỉnh trong một thời gian. Tôi sẽ vá và biên dịch kernel của mình trên cùng một máy tính mà tôi dự định sử dụng nó, điều đó có nghĩa là tôi có thể mất môi trường phát triển nếu tôi tạo một kernel bị lỗi. Vì vậy, tôi đã đảm bảo luôn giữ một kernel tốt đã biết trong menu GRUB của mình, vì vậy nếu tôi mắc lỗi, tôi đã trở lại môi trường phát triển tốt với khởi động lại đơn giản.

Phối hợp điều đó với một nhóm là khó khăn, nhưng tôi cho rằng chủ yếu là cho phép bất cứ ai bắt đầu dự phòng và truyền đạt lý do. Trong kiểm soát phiên bản, một cách để chỉ định đó là với một cái gì đó như một last_known_goodnhánh, ở đâu đó giữa developvà mastertrong quy trình làm việc của bạn. Không có gì được đẩy ở đó cho đến khi bạn đã xây dựng thành công bản dựng.

Nếu công cụ này đang được sử dụng để sản xuất phần mềm chất lượng sản xuất (đặc biệt là nếu nó đang được sử dụng đệ quy, tức là để phát triển chính nó), tôi sẽ tăng các nỗ lực thử nghiệm trước của bạn và chờ cho đến khi phát hành đủ cho đến khi bạn phát hành đủ ổn định khá tự tin bạn sẽ không phá vỡ mã sản xuất bằng cách sử dụng nó.

Nếu bạn phải chờ phiên bản chính để có mức độ tự tin đó, thì hãy là nó.

Git cũng là một công cụ như vậy và rõ ràng cũng làm dogfooding. Nhưng nó làm điều đó đến mức độ khác nhau trong các môi trường khác nhau. Các máy chủ công cộng chỉ chạy bản phát hành trong khi các nhà phát triển thường làm việc với next(tên git của dự án là "phát triển") hoặc pu(thậm chí phát triển hơn phát triển). Bất kỳ nhà phát triển nào bị chặn bởi một số vấn đề đều có thể quay lại nexthoặc masterphát hành lần cuối bất cứ khi nào họ bị chặn bởi một cái gì đó và kho lưu trữ chính không bị ảnh hưởng, vì vậy các vấn đề có thể được làm sạch bằng cách tham khảo nó.

Mô hình phân nhánh tương tự như trên với các tên hơi khác nhau. masterlà những gì các bản phát hành lớn được thực hiện, maintlà nhánh phát hành cho bản phát hành điểm tiếp theo, nexttương tự như phát triển với sự khác biệt nhỏ mà các tính năng có thể được hợp nhất để làm chủ riêng sau khi đã có trong bản kế tiếp thay vì toàn bộ phần tiếp theo được hợp nhất.

Có một chi nhánh thêm pu. Điều này được tạo ra bằng cách hợp nhất tất cả các nhánh tính năng được xem xét để tích hợp với nhau next(nhánh bị loại bỏ và được tạo lại mỗi lần). IIRC nó chỉ được xuất bản nếu nó vượt qua bộ thử nghiệm. Lần cuối tôi nhìn Junio, người bảo trì, đang chạy các kịch bản để xây dựng nó thường xuyên bằng tay, nhưng các kịch bản như vậy có thể được chạy bằng cách tích hợp liên tục hàng đêm và tôi tin rằng Gerrit thậm chí tự động tạo ra nó.

Vì vậy, loại đó là câu trả lời. Bạn dogfood phiên bản phát triển nhất bạn có trong môi trường phát triển, nhưng sử dụng bản phát hành trước để phát hành bản dựng.

Dựa trên câu trả lời được chấp nhận , tôi sẽ mở rộng quy trình phân nhánh để duy trì các nhánh tương tự như sau:

• master: hợp nhất với release-*khi đóng cửa
• dogfood: chi nhánh từ master; bao gồm các bản sửa lỗi được xác định trong khi dùng thức ăn cho chó; hợp nhất từ developkhi phần mềm được coi là "ổn định" để sử dụng nội bộ; người đứng đầu chi nhánh này có thể được di chuyển ngược thời gian nếu cần
• develop: chi nhánh từ master; bao gồm các thay đổi đang diễn ra, sửa lỗi và hợp nhất từ dogfoodvà feature-*các nhánh
• feature-*: chi nhánh từ develop; bao gồm các thay đổi cho một tính năng mới cụ thể
• release-*: các nhánh từ dogfoodkhi phần mềm được coi là "ổn định" để sử dụng bên ngoài; bao gồm các cập nhật tài liệu và các lỗi nhỏ trước khi hợp nhất vớimaster