Phiên bản ngữ nghĩa trong Agile

Giả sử tôi có 14 ngày chạy nước rút trong đó tôi có một vài câu chuyện cho các tính năng mới, một vài cải tiến và một số lỗi cần khắc phục. Tôi cũng triển khai những thay đổi đó khi chúng sẵn sàng, tôi không chờ kết thúc nước rút.

Vấn đề của tôi là - làm thế nào để theo dõi phiên bản ngữ nghĩa của các sản phẩm được phát triển và duy trì như thế này? Nếu cứ sau 14 ngày sẽ phát hành thì sẽ dễ dàng, tôi sẽ tăng số phiên bản và lưu ý tất cả các thay đổi trong thay đổi. Nhưng nếu thay đổi được triển khai liên tục thì sao? Có nên tăng phiên bản mỗi khi một cái gì đó được triển khai? Hoặc tôi nên đợi cho đến khi nước rút kết thúc và sau đó, tạo một số "sơ yếu lý lịch" và tăng số phiên bản chỉ một lần mỗi lần lặp độc lập khi triển khai thực tế? Thực hành tốt nhất cho phiên bản ngữ nghĩa trong Agile là gì?

EDIT: Để giải thích rõ hơn nhu cầu của tôi, tôi muốn thay đổi cho các bên liên quan ở nơi đầu tiên. Tôi không nghĩ họ sẽ quan tâm đến bản ghi mới trong changelog sau mỗi thay đổi được triển khai.

Đối với quản lý phát hành điển hình, bạn sẽ muốn số xây dựng được tạo bởi hệ thống xây dựng của mình để các DLL được phiên bản mỗi khi chúng được triển khai. Điều này sẽ đảm bảo sau này bạn có thể kiểm tra phiên bản nào được triển khai trên một máy chủ nhất định.

Phiên bản 'tiếp thị' của bạn, thường được đưa vào ghi chú phát hành hoặc xuất bản lên trang web của bạn không nên được cập nhật mỗi phiên bản. Những ghi chú phát hành nên được tích lũy và nhóm lại với nhau, có khả năng là thời gian kết thúc nước rút của bạn.

Nếu lược đồ phiên bản ngữ nghĩa cổ điển "MAJOR.MINOR.PATCH" có ý nghĩa, tùy thuộc vào người bạn triển khai và đặc biệt là khi nào và tần suất bạn triển khai cho người dùng cuối . Lược đồ này hữu ích nhất nếu bạn làm việc với bản phát hành ổn định "4.5", trong đó bạn bắt đầu bằng 4.5.0. Các phiên bản 4.5.1, 4.5.2, v.v chỉ chứa các bản sửa lỗi, trong khi bạn đã hoạt động nội bộ trên phiên bản 4.6.

Ví dụ: nếu bạn cung cấp "nhánh ổn định" cho người dùng cuối của mình, hãy cung cấp cho nó phiên bản 4.5.0 để triển khai ban đầu và 4.5.1, 4.5.2 bất cứ khi nào bạn phát hành bản vá. Trong quá trình phát triển "nhanh nhẹn" nội bộ và triển khai giữa nước rút, bạn đã có thể có phiên bản 4.6, chỉ cần gọi nó là "phiên bản beta". Bất cứ khi nào bạn triển khai nó ở giữa nước rút, hãy thêm số bản dựng được tạo tự động như "4.6.beta build 123". Khi chạy nước rút của bạn kết thúc, gán nó "4.6.0" và chuyển số phiên bản cho lần chạy nước rút tiếp theo bên trong thành "4.7". Bắt đầu với ".0" chỉ là quy ước, bạn cũng có thể sử dụng ".0" để gắn thẻ các phiên bản beta và bắt đầu bằng ".1" cho người dùng cuối của mình. IMHO từ "beta" có ý nghĩa hơn nhiều, nói với mọi người rằng nước rút "chưa hoàn thành".

Nếu bạn phát hành nhật ký thay đổi người dùng cuối đầy đủ với mỗi phiên bản beta là tùy thuộc vào bạn, nhưng ít nhất vào cuối giai đoạn nước rút, nhật ký thay đổi sẽ được hoàn thành và bất cứ khi nào bạn cung cấp một lỗi cho người dùng cuối, bạn cũng nên cập nhật các tài liệu lịch sử.

Bạn sẽ tìm thấy chiến lược phát hành hai nhánh riêng biệt, một nhánh "ổn định" với số phiên bản ngữ nghĩa và "nhánh phát triển" được đánh dấu bằng số xây dựng hoặc một cái gì đó tương tự, trong nhiều sản phẩm nguồn mở như Inkscape, Firefox hoặc 7-zip.

Tuy nhiên, nếu bạn không làm việc với các nhánh phát triển và ổn định riêng biệt và phát hành phiên bản mới cho người dùng cuối hàng ngày, bạn cũng nên tăng số phiên bản hàng ngày. Trong trường hợp như vậy, các số phiên bản "4.5.1", "4.5.2", ... có thể sẽ phản ánh các triển khai riêng lẻ của bạn và không cho biết sự khác biệt giữa sửa lỗi và các thay đổi khác. Điều đó có thể ổn, nó không còn là "phiên bản ngữ nghĩa" cổ điển nữa. Trong kịch bản này, bạn cũng có thể triển khai các phiên bản 4.5, 4.6, 4.7, 4.8, không có sự khác biệt thực sự.

Liên quan đến câu hỏi của bạn về các mục trong thay đổi của bạn: IMHO khi một cái gì đó hiển thị cho người dùng cuối, nó đáng giá một mục trong thay đổi, ngay khi bạn triển khai thay đổi. Ví dụ: nếu bạn sử dụng các tính năng bật tắt và thực hiện các thay đổi đối với một số tính năng nửa nướng chưa được kích hoạt cho người dùng, thì điều đó không thuộc về một thay đổi. Nếu bạn chỉ tái cấu trúc, không có thay đổi rõ ràng cho người dùng, thì đó không thuộc về một thay đổi. Nếu bạn sửa một lỗi có thể ảnh hưởng đến một số người dùng, thì đó chắc chắn thuộc về thay đổi - và nó sẽ được đề cập ở đó cùng lúc khi bạn triển khai lỗi. Và nó không quan trọng nếu bạn phát hành hàng ngày hoặc hàng tháng hoặc hàng năm.

Tôi sẽ sử dụng số xây dựng. Thông thường, số bản dựng sẽ tương ứng với phiên bản cao nhất của hệ thống kiểm soát phiên bản. Nếu số bản dựng thứ hai là 1745 và đã được kiểm tra 5 thay đổi trong ngày thứ ba, số bản dựng vào buổi tối thứ ba sẽ là 1750.

Sau đó, làm một bản tóm tắt ngắn cho những gì đã thay đổi giữa 1745 và 1750.

Sau đó, mỗi khi bạn cập nhật số phiên bản của hệ thống, bạn có thể thêm tất cả các bản tóm tắt ngắn từ các bản dựng để có được các thay đổi từ số phiên bản cuối cùng sang bản mới.

Phương pháp ưa thích của tôi mà tôi đã sử dụng ít nhất một vài năm nay là tăng số sau mỗi câu chuyện được hoàn thành. Điều này có nghĩa là các phiên bản được phát hành vào cuối giai đoạn nước rút sẽ không liên tục, ví dụ sau ngày 1.2.3, bạn có thể tìm thấy 1.5.2 thay vì 1.4.0.

Trong thay đổi, bạn có thể liệt kê các phiên bản trung gian với các mô tả tương ứng hoặc chỉ nhóm tất cả các thay đổi thành phiên bản "đã phát hành" và bỏ qua các phiên bản ở giữa.

Ban đầu, tôi sợ người dùng sẽ thấy "lỗ hổng" giữa các số phiên bản có vấn đề, nhưng một khi họ biết về nó, đó không phải là vấn đề trong thực tế. Ưu điểm lớn là việc tăng số lượng sau mỗi câu chuyện làm cho quá trình ít bị lỗi hơn - bạn không phải kiểm tra toàn bộ công việc từ 2 tuần để quyết định số phiên bản tiếp theo sẽ là gì - khi nhìn vào một câu chuyện, rõ ràng . Ngoài ra, "bước nhảy vọt" về số phiên bản giữa mỗi lần phát hành đưa ra ước tính sơ bộ về số lượng thay đổi đã được đưa vào bản phát hành. Nói chung, tôi thấy hệ thống này hoạt động tốt (điều này là với khách hàng nội bộ công ty, nhưng nếu bạn đã làm việc trong một chu kỳ phát hành nhanh thì nó cũng sẽ hoạt động cho khách hàng bên ngoài).