Có tốt không khi lưu trữ số phiên bản phần mềm trong VCS?

Một phiên bản sản phẩm, chẳng hạn v1.0.0.100, không chỉ thể hiện một bản phát hành sản xuất phần mềm duy nhất, mà còn giúp xác định các bộ tính năng và các giai đoạn hotfix cho sản phẩm nói trên. Ngay bây giờ tôi thấy hai cách để duy trì phiên bản gói / bản dựng / nhị phân cuối cùng của sản phẩm:

Kiểm soát phiên bản. Một tập tin ở đâu đó lưu trữ số phiên bản. Máy chủ xây dựng Tích hợp liên tục (CI) sẽ có một tập lệnh để xây dựng phần mềm sử dụng số phiên bản đã đăng ký này để áp dụng nó cho tất cả các lĩnh vực của phần mềm cần thiết (nhị phân, gói cài đặt, trang trợ giúp, tài liệu, v.v.).
Môi trường và / hoặc xây dựng các tham số. Chúng được duy trì bên ngoài kiểm soát phiên bản (nghĩa là chúng không được gắn với snapshot / tag / Branch). Các tập lệnh xây dựng phân phối và sử dụng số theo cùng một cách, tuy nhiên chúng chỉ nhận được giá trị khác nhau (nó được cung cấp cho tập lệnh xây dựng, thay vì để tập lệnh biết nơi lấy nó so với cây nguồn).

Vấn đề với cách tiếp cận đầu tiên là nó có thể làm phức tạp sự hợp nhất giữa các nhánh chính. Nếu bạn vẫn duy trì 2 bản phát hành song song của cùng một phần mềm, bạn sẽ giải quyết xung đột khi hợp nhất giữa hai dòng chính nếu phiên bản đã thay đổi trên cả hai kể từ lần hợp nhất cuối cùng.

Vấn đề với cách tiếp cận thứ hai là hòa giải. Khi bạn quay lại bản phát hành 1 năm trước, bạn sẽ chỉ dựa vào thông tin thẻ để xác định số phát hành của nó.

Trong cả hai trường hợp, có thể có một số khía cạnh nhất định của số phiên bản không được biết trước khi xây dựng CI. Ví dụ, bản dựng CI có thể được lập trình đặt vào thành phần thứ 4 thực sự là số bản dựng tự động (ví dụ: bản dựng thứ 140 trên nhánh). Nó cũng có thể là một số sửa đổi trong VCS.

Cách tốt nhất để theo kịp số phiên bản của phần mềm là gì? Các phần "đã biết" có nên luôn được duy trì trong VCS không? Và nếu vậy, các xung đột trên các nhánh chính có phải là một vấn đề không?

Ngay bây giờ, chúng tôi duy trì số phiên bản của mình thông qua các tham số được chỉ định và duy trì trong kế hoạch xây dựng CI (Atlassian Bamboo). Chúng tôi phải cẩn thận trước khi hợp nhất với masterchi nhánh của mình rằng các số phiên bản được thiết lập đúng trước khi xây dựng CI khởi động . Liên quan đến quy trình công việc Gitflow, tôi cảm thấy rằng nếu số phiên bản được theo dõi trong kiểm soát nguồn, chúng tôi có thể đảm bảo nó được thiết lập đúng khi chúng tôi tạo releasechi nhánh để chuẩn bị phát hành. QA sẽ thực hiện thử nghiệm tích hợp / khói / hồi quy cuối cùng trên nhánh này và sau khi đăng nhập, một sự hợp nhất sẽ masterdiễn ra để báo hiệu cam kết phát hành.

— void.pulum
nguồn

Là một xung đột hợp nhất giữa hai phiên bản của một tệp version.txttrong đó một phiên bản chứa một dòng duy nhất 1.0.7và phiên bản kia 1.2.0thực sự khó giải quyết? Nếu đây là xung đột duy nhất trong việc hợp nhất hai chi nhánh đã tách ra, tôi sẽ coi mình là người rất may mắn. Làm thế nào thường xảy ra? Nếu nó xảy ra, không phải là một điều tốt mà bạn buộc phải suy nghĩ về số phiên bản mà phiên bản hợp nhất nên có? (Xin lỗi vì đã sử dụng một cách mơ hồ từ phiên bản phiên bản.)

— 5gon12eder

@ 5gon12eder Những khó khăn hoặc cảm giác về việc hợp nhất chính nó là không liên quan. Đó chỉ là một khía cạnh tiêu cực của giải pháp tổng thể.

— void.pulum

Câu trả lời:

Cá nhân, tôi chọn tùy chọn 3: giữ thông tin phiên bản trong siêu dữ liệu VCS , cụ thể là các thẻ.

Git làm cho nó rất dễ dàng để làm như vậy, bởi vì có một lệnh git describe, có thể mô tả duy nhất một cam kết dựa trên một thẻ. Đây là cách nó hoạt động:

Nếu cam kết hiện tại được gắn thẻ, hãy xuất tên của thẻ.
Mặt khác, đi ngược lịch sử cho đến khi bạn tìm thấy một thẻ và sau đó xuất ra một mô tả theo định dạng sau : <tag>-<number of commits since the tag>-g<abbreviated commit hash>.
Nếu có những thay đổi không được cam kết trong worktree, hãy chắp thêm -dirty.

Vì vậy, nếu bạn đang thực hiện xây dựng bản phát hành và có cam kết được gắn thẻ 1.2.3, nó sẽ xuất ra 1.2.3. Nếu bạn hiện đang làm việc trên 1.2.4 và bạn đã thực hiện 4 lần xác nhận kể từ 1.2.3 và có các thay đổi không được cam kết trong cây, nó sẽ xuất ra 1.2.3-4-gdeadbee-dirty.

Điều này được đảm bảo là duy nhất và đơn điệu, cũng như con người có thể đọc được, và do đó có thể được sử dụng trực tiếp như một chuỗi phiên bản. Điều duy nhất bạn phải đảm bảo là một quy ước đặt tên thích hợp cho các thẻ.

— Jorg W Găngag
nguồn

Tôi thực sự thích ý tưởng này, nhưng điều này có vẻ khó quản lý với JIRA + Bamboo. Tre chỉ hoạt động trên các nhánh, không phải thẻ, vì vậy bạn phải đảm bảo thẻ được đẩy trước khi tạo bản dựng. Đây là lỗi dễ xảy ra.

— void.pulum

git describecũng hoạt động với các nhánh: " --all - Thay vì chỉ sử dụng các thẻ chú thích, hãy sử dụng bất kỳ ref nào được tìm thấy trong refs/không gian tên. Tùy chọn này cho phép khớp với bất kỳ nhánh nào, nhánh theo dõi từ xa hoặc thẻ nhẹ." Không chắc chắn làm thế nào điều này làm việc với Tre, mặc dù. (Điều này tất nhiên sẽ yêu cầu đặt tên các nhánh cẩn thận, giống như chế độ bình thường với các thẻ.)

— Jörg W Mittag

Tôi biết một số người phát hành hoàn toàn tự động từ Git. Chuỗi phiên bản được xây dựng bởi git describe, ChangeLog được tạo từ git shortlog(thực ra là từ tập lệnh phân tích cú pháp đầu ra git log --pretty=tformat:<some custom format string>) và ghi chú phát hành được tạo từ mô tả thẻ và được git notesđính kèm với các cam kết quan trọng.

— Jörg W Mittag

Quan điểm của tôi là, thẻ sẽ cần phải được tạo trước khi phát hành để cam kết sau khi được phiên bản chính xác với số cơ sở. Điều này đi ngược lại với nguyên tắc gắn thẻ trong hoặc tại thời điểm phát hành. Tre nhặt lên các bản dựng tự động dựa trên các cam kết master(từ develop, hãy nhớ rằng tôi đang sử dụng gitflow). Điều gì xảy ra nếu ai đó đẩy một sự hợp nhất đến mastermà không có thẻ? Nó sẽ không sử dụng phiên bản phù hợp (thực tế là nó sẽ sử dụng phiên bản của phiên bản cuối cùng )

— void.pulum

Nếu bạn sử dụng một lược đồ như thế này, việc gắn thẻ sẽ được phát hành. Ah, tôi thấy những gì bạn đang nhận được, tôi nghĩ. Vì vậy, hiện tại, máy chủ CI của bạn là trình điều khiển phát hành và với thay đổi này, SCM là trình điều khiển phát hành, nhưng bạn có muốn nó vẫn như vậy không?

— Jörg W Mittag

Vâng. Đó là một thực hành tốt để giữ hầu hết số phiên bản trong vcs. Nếu chúng tôi xem xét semver.org phiên bản ngữ nghĩa nơi chúng tôi có Major.minor.patch.build, ba người đầu tiên phải sống trong vcs. Số cuối cùng có thể là số tăng từ máy chủ xây dựng của bạn được sử dụng để quay lại cam kết cụ thể mà nhị phân được tạo từ đó.

Để tạo điều kiện thuận lợi cho .NET, chúng tôi đã tạo một exe dòng cmd nhỏ được cam kết với git. Với một sự kiện dựng sẵn, nó chọn số bản dựng mà teamcity được gắn thẻ trong quá trình xây dựng. Công cụ dòng cmd này tự động tạo một lớp với một hằng số chứa số bản dựng. Phần còn lại của số phiên bản: Major.minor.patch chỉ là một hằng số bình thường trong một tệp khác. Hai tệp được chia sẻ này được bao gồm trong mọi hội đồng trong một giải pháp dưới dạng liên kết (alt + shift-drag).

Cách tiếp cận này đủ mạnh để chúng ta có thể xây dựng teamcity và kiểm tra mã của mình. Nhấn vào phương vị và yêu cầu kudu xây dựng lại nhưng với số bản dựng teamcity là phiên bản của dll's.

— Pedben Skov Pedersen
nguồn