Cách tốt nhất để tạo ra một thay đổi phát hành chính xác là gì?

Tôi đang làm việc trên một số dự án mà tôi muốn cung cấp một thay đổi chính xác cho mỗi bản phát hành, nhưng tôi chưa tìm thấy một phương pháp nào để thu thập các thay đổi đó sẽ hoạt động mà không gặp rắc rối. Vấn đề chủ yếu là khi thời gian giữa các phiên bản dài và mỗi phiên bản có rất nhiều tính năng và sửa lỗi và khi phần mềm có một số nhánh được phát triển cùng một lúc.

Một số tùy chọn tôi đã xem xét:

1. Xây dựng các thay đổi từ các thông điệp cam kết và yêu cầu các nhà phát triển viết các thông điệp như thể họ sẽ viết một dòng cho các thay đổi (mà họ sẽ thực hiện một cách hiệu quả).
   • Có thể không hoạt động khi có nhiều nhánh và hợp nhất giữa các nhánh (có thể khó biết được cam kết nào cuối cùng đã kết thúc trong bản phát hành).
2. Yêu cầu rằng đối với mỗi thay đổi trong mã phải có một vé tương ứng trong hệ thống theo dõi lỗi. Thay đổi có thể được viết dựa trên vé.
   • Các nhà phát triển có thể cảm thấy bực bội khi kiếm một vé cho những thay đổi nhỏ, đặc biệt là nếu việc bán vé mất nhiều thời gian hơn sửa lỗi.
3. Yêu cầu các nhà phát triển luôn cập nhật thay đổi (dưới dạng tệp văn bản trong gốc dự án) cùng lúc khi họ thực hiện thay đổi mã.
   • Cảm thấy như lao động thủ công có thể được tự động.
4. Yêu cầu người quản lý dự án lấy khác biệt của phiên bản hiện tại và phiên bản trước đó và viết thay đổi tại thời điểm đó dựa trên những gì họ thấy đã được thay đổi.
   • Công việc bổ sung cho người chịu trách nhiệm phát hành và có thể không rõ ràng hiệu quả thực tế của thay đổi chỉ bằng cách xem mã.
5. Chỉ gửi các tính năng đã được lên kế hoạch để phát hành; bạn có thể viết thay đổi ngay cả trước khi bạn bắt đầu viết mã.
   • Không phải là một lựa chọn thực sự trừ khi bạn đang sử dụng mô hình thác nước.

Tôi đã từng sử dụng từng loại này hoặc một biến thể của chúng trong quá khứ nhưng chúng quá không đáng tin cậy, tốn nhiều công sức hoặc cứng nhắc. Có ai có một viên đạn ma thuật hoặc ý tưởng tốt về cách giải quyết vấn đề?

Nếu bạn chưa có yêu cầu về vé cho mỗi thay đổi, thì việc các nhà phát triển tạo một vé cho mỗi thay đổi đủ quan trọng để kết thúc trong nhật ký thay đổi có vẻ hợp lý.

Nếu thay đổi đủ quan trọng để nói cho người dùng biết, thì có lẽ bạn muốn thực hiện thay đổi đó dưới một vé, và viết vé mô tả là một cách làm tốt. Ngoài ra, bạn có thể kết nối điều này với bất kỳ phiên bản phát hành và lộ trình hỗ trợ trình theo dõi lỗi của bạn.

Cảm thấy như lao động thủ công có thể được tự động.

Làm thế nào nó có thể được tự động? Không cần chỉnh sửa thay đổi trên mỗi cam kết, mà chỉ khi một tính năng đáng nói được thêm vào. Điều đó có xảy ra quá thường xuyên trên phần mềm của bạn đến nỗi việc thêm một dòng vào thay đổi mỗi lần không?

Bạn có thể nói đây là nhiệm vụ của QA để cập nhật thay đổi, nhưng một số hệ thống quản lý cấu hình phần mềm hoặc trình theo dõi sự cố có thể tự động tạo ra thay đổi cho bạn, rất hữu ích trong môi trường nhiều nhà phát triển. Điều này giả định rằng bạn đang sử dụng tính năng / vấn đề theo dõi theo cách nó được dự định.

Ví dụ, trình theo dõi vấn đề nguồn mở Trac có ChangeLogMacro .

Các trình theo dõi vấn đề khác có thể có macro hoặc trình cắm có thể tạo ra thay đổi cho bạn. Đây thường là một truy vấn đơn giản để chọn tất cả các vé / vấn đề đã được đóng giữa bản phát hành cuối cùng và bản phát hành hiện tại.