Chính xác số xây dựng trong MAJOR.MINOR.BUILDNUMBER.REVISION là gì

Những gì tôi nghĩ về Build Numbers là bất cứ khi nào một bản dựng hàng đêm mới được tạo, một BUILDNUMBER mới được tạo và gán cho bản dựng đó. Vì vậy, đối với ứng dụng phiên bản 7.0 của tôi, các bản dựng hàng đêm sẽ là 7.0.1, 7.0.2, v.v. Có phải vậy không Sau đó, việc sử dụng một REVISION sau số xây dựng là gì? Hoặc là phần REVISION đang được tăng lên sau mỗi lần xây dựng hàng đêm? Tôi có một chút bối rối ở đây ... chúng ta có đề cập đến việc xây dựng hàng đêm như một BUILD không?

Định dạng được đề cập ở đây: AssociationVersion - MSDN

Tôi chưa bao giờ thấy nó được viết ra trong hình thức đó. Nơi tôi làm việc, chúng tôi đang sử dụng mẫu MAJOR.MINOR.REVISION.BUILDNUMBER, trong đó MAJOR là một bản phát hành chính (thường là nhiều tính năng mới hoặc thay đổi cho UI hoặc HĐH cơ bản), MINOR là một bản phát hành nhỏ (có thể là một số tính năng mới) trên bản phát hành chính trước đó, REVISION thường là bản sửa lỗi cho bản phát hành nhỏ trước đó (không có chức năng mới) và BUILDNUMBER được tăng lên cho mỗi bản sửa đổi mới nhất.

Ví dụ: bản sửa đổi có thể được phát hành cho QA (kiểm soát chất lượng) và chúng quay trở lại với một vấn đề đòi hỏi phải thay đổi. Lỗi này sẽ được sửa và được phát hành trở lại QA với cùng số REVISION, nhưng số BUILDNUMBER tăng lên.

Toàn bộ sự nhầm lẫn bắt nguồn từ các ngữ nghĩa khác nhau mà MS sử dụng cho "Số lượng xây dựng" và đặc biệt là "Sửa đổi". Các thuật ngữ chỉ có nghĩa là những điều khác nhau.

Hầu hết mọi người (bao gồm cả tôi) sử dụng sơ đồ đánh số phiên bản ngữ nghĩa trong đó bạn chỉ cần có số BUILD cao hơn bất cứ khi nào bạn phải tạo một bản dựng mới vì bất kỳ lý do gì. Đối với chúng tôi, một hotfix được coi là một thay đổi mã khác và phần BUILD sẽ tự động tăng lên sau mỗi lần chạy CI. Các mô-đun có cùng MAJ.MIN.REV được coi là có thể hoán đổi cho nhau và BUILD cho bạn biết cái nào là gần đây nhất.

Tuy nhiên, REVISION tăng cho thấy một nhánh phát hành vĩnh viễn mới, đó là lý do tại sao chúng tôi đặt nó trước BUILD. Nhược điểm của phương pháp đó là chúng ta có thể nhận được chuỗi các sự kiện sau:

• cam kết số 4711: Alice thêm tính năng A
• CI sản xuất bản dựng 1.2.3.100
• cam kết số 4712: Bob sửa đổi tính năng B
• cam kết số 4713: Alice đã sửa tính năng A ("hotfix")
• CI sản xuất bản dựng 1.2.3.101

Như bạn có thể thấy, hotfix không phải là thay đổi duy nhất có trong bản dựng tiếp theo, cũng là sửa đổi của Bob trở thành một phần của bản dựng đó. Nếu bạn muốn ổn định chi nhánh hiện tại, bạn có thể gặp rắc rối vì bạn không bao giờ có thể chắc chắn liệu Bob có thêm một loạt lỗi hay không.

MS sử dụng cả hai thuật ngữ khác nhau. Số BUILD không được tự động tăng lên, thay vào đó, nó có thể được coi là một loại nhánh phát hành, để đóng băng mã được sử dụng cho một phiên bản mã cụ thể. REVISION chỉ ra các thay đổi "nóng" bổ sung được áp dụng cho chi nhánh BUILD đó. Trình tự do đó sẽ như sau:

• cam kết số 4711: Alice thêm tính năng A vào thân cây / chủ
• Carl tạo chi nhánh xây dựng 1.2.100
• CI sản xuất bản dựng 1.2.100.0
• cam kết số 4712: Bob sửa đổi tính năng B trong thân cây / chủ
• cam kết số 4713: Alice cố định tính năng A trong 1.2.100chi nhánh
• CI sản xuất bản dựng 1.2.100.1

Thuật ngữ REVISION có thể đề cập đến

• một sản phẩm sửa đổi (đó là cách hầu hết mọi người sử dụng nó)
• bản sửa đổi của bản dựng hàng ngày cụ thể (đó là những gì MS làm)

Sự khác biệt chính giữa hai quy trình là, bạn có muốn áp dụng hotfix cho các bản dựng CI hay không và do đó, tại thời điểm nào trong quy trình, chi nhánh được thực hiện. Khía cạnh này trở nên quan trọng khi bạn muốn có thể chọn một bản dựng cụ thể bất cứ lúc nào sau khi tất cả các thử nghiệm thành công và quảng bá chính xác phiên bản đó lên bản phát hành chính thức tiếp theo của sản phẩm.

Trong trường hợp của chúng tôi, công cụ CI tạo thẻ kho lưu trữ, vì vậy chúng tôi luôn có sẵn thông tin cần thiết để sử dụng khi cần. Với SVN, nó trở nên đơn giản hơn, bởi vì các thẻ và các nhánh được triển khai chính xác theo cùng một cách - một thẻ không có gì khác hơn một nhánh nằm bên dưới /tags.

Xem thêm

Từ phần FAQ tại chiến lược phân nhánh TFS :

Tôi nên sửa vé P1 (hotfix) ở chi nhánh nào?

• P1 nên được cố định trong nhánh gần nhất với cơ sở mã đang chạy trong Sản xuất. Trong trường hợp này, nên sửa lỗi P1 trong nhánh Prod. Bằng cách áp dụng sửa lỗi trong bất kỳ chi nhánh nào khác và đưa ra các thay đổi cho sản xuất, bạn có nguy cơ phát hành mã bán thành phẩm hoặc chưa được kiểm tra từ các lần lặp tiếp theo.

• Bây giờ bạn có thể tranh luận nếu an toàn khi làm việc trực tiếp với chi nhánh Prod, hãy nghĩ lại, một chiếc P1 đòi hỏi sự chú ý ngay lập tức không phải là vấn đề cơ bản trong hệ thống. Trong trường hợp đó là một vấn đề cơ bản, nó cần được thêm vào hồ sơ tồn đọng của Sản phẩm vì nó có thể yêu cầu phân tích và thảo luận thêm với khách hàng.

Một cách đọc tốt khác là hướng dẫn phân nhánh TFS

Microsoft mô tả mục đích của từng thành phần của số phiên bản .NET trong tài liệu MSDN của họ cho Versionlớp. Đây là phần có liên quan:

Major.minor [.build [.revision]]

Các thành phần được sử dụng theo quy ước như sau:

Major: Các hội đồng có cùng tên nhưng các phiên bản chính khác nhau không thể thay thế cho nhau. Số phiên bản cao hơn có thể chỉ ra việc viết lại chính của sản phẩm trong đó không thể giả sử tính tương thích ngược.

Nhỏ: Nếu tên và số phiên bản chính trên hai cụm là giống nhau, nhưng số phiên bản phụ là khác nhau, điều này cho thấy sự tăng cường đáng kể với ý định tương thích ngược. Số phiên bản nhỏ hơn cao hơn này có thể cho thấy một bản phát hành điểm của sản phẩm hoặc phiên bản mới của sản phẩm hoàn toàn tương thích ngược.

Bản dựng: Sự khác biệt về số bản dựng thể hiện việc biên dịch lại cùng một nguồn. Các số bản dựng khác nhau có thể được sử dụng khi bộ xử lý, nền tảng hoặc trình biên dịch thay đổi.

Sửa đổi: Các hội đồng có cùng tên, số phiên bản chính và số phiên bản nhỏ nhưng các phiên bản khác nhau được dự định có thể hoán đổi cho nhau. Số sửa đổi cao hơn có thể được sử dụng trong bản dựng sửa lỗ hổng bảo mật trong bản lắp ráp được phát hành trước đó.

http://msdn.microsoft.com/en-us/l Library / system.version.aspx

Có ít nhất một vài điều khác nhau mà tôi có thể tưởng tượng được số tham chiếu xây dựng:

1. Phiên bản kiểm soát nguồn đã được phát hành. Ví dụ: nếu có bản phát hành bản sửa đổi # 12345, thì bản này có thể được theo dõi bằng cách có số bản dựng và nếu bản vá đó là bản sửa đổi có thể tăng lên vì nó không phải là chức năng mới sẽ tăng các phiên bản chính hoặc phụ và số bản dựng phải được ghi nhớ trong trường hợp ai đó muốn chạy lại bản dựng đó.

2. Định danh máy chủ tích hợp liên tục. Trong trường hợp này, máy chủ CI có thể đánh số từng bản dựng mà nó chạy và do đó số bản dựng là thứ mà bản dựng thành công đạt được và phần sửa đổi không cần thiết trong kịch bản này.

Có thể có những cái khác mà tôi không biết, nhưng đây là những cái lớn mà tôi biết khi nói đến các con số trên cơ sở mã.

Số bản dựng thường được tăng lên ở mỗi bản dựng nên nó là duy nhất.

Để đơn giản, một số đặt lại số bản dựng bất cứ khi nào số MAJOR hoặc MINOR bị va đập.

Hầu hết các công cụ tích hợp liên tục cho phép các số bản dựng duy nhất được tạo tự động.

Bản sửa đổi có thể được sử dụng cho các bản vá của các bản dựng. Hãy nói rằng 2 đội làm việc trên một sản phẩm.

Nhóm 1 là nhóm phát triển chính và tạo bản dựng hàng đêm với lược đồ phiên bản sau 1.0.X.0, trong đó X được tăng lên. Bây giờ, họ đang ở bản dựng 1.0.50.0 Đội 2 thỉnh thoảng sẽ xây dựng bản dựng. Giả sử họ lấy bản dựng từ tuần trước là 1.0.43.0 và bắt đầu sử dụng. Đội 1 tiến lên 1.0.51.0 khi đội 2 tìm thấy sự cố trong 1.0.43.0.

Bây giờ nhóm 1 sẽ lấy bản dựng đó (43), khắc phục sự cố và cung cấp cho nhóm 2 bản dựng 1.0.43.1. Bản sửa lỗi cũng có thể được phổ biến trong bản dựng chính, vì vậy thay đổi sẽ xuất hiện trong 1.0.52.0.

Hy vọng điều này là rõ ràng và hữu ích.

* Sửa đổi là hữu ích khi không phải tất cả mọi người tham gia vào dự án đều sử dụng cùng một bản dựng và bạn cần vá các bản dựng cụ thể.

Hãy để tôi nói cách tôi nhìn và sử dụng nó ....

Phiên bản tên chương trình Major.minor.build.revision

chính: Đối với tôi là dự án hiện tại tôi đang làm việc. Số sẽ không thay đổi cho đến khi tôi bắt đầu một dự án mới có cùng tên chương trình. Điều này có nghĩa là tôi sẽ viết một chương trình mới có cùng giới tính (ví dụ: access v1 - access v-2 - access v-3 * tất cả cùng một chương trình nhưng được viết lại hoàn toàn).

nhỏ: Điều này có nghĩa là tôi đang thêm chức năng cho dự án được xuất bản hiện tại. Ví dụ, có thể tôi đã thêm khả năng in biên lai hoặc thêm khả năng nhập ảnh. Về cơ bản chức năng bổ sung tôi muốn thêm ngay bây giờ và không chờ đợi phiên bản chính tiếp theo thực hiện.

build: Cái này tôi dùng để chỉ những thay đổi rất nhỏ trong phiên bản Major.minor đã xuất bản. Đây có thể là một sự thay đổi trong bố cục, bảng màu, vv

sửa đổi: Điều này tôi sử dụng để chỉ ra một sửa lỗi trong Major.minor.build được xuất bản hiện tại - Có những lúc tôi không tiến hành dự án hiện tại và phát sinh lỗi. Lỗi này cần được sửa chữa và công bố. Nó chỉ có nghĩa là tôi đang sửa chữa những gì tôi đã xuất bản để hoạt động đúng. Tôi cũng sẽ sử dụng điều này nếu tôi đang làm việc trên một bản dựng mới, một bổ sung mới hoặc bắt đầu một phiên bản chính mới. Phiên bản đã xuất bản rõ ràng cần phải được vá trong khi chúng tôi đang chờ bản phát hành chính, phụ hoặc bản dựng tiếp theo.

Vì vậy, theo cách này, một dự án đã hoàn thành hoặc bị đình trệ vẫn có thể được sửa chữa và có thể sử dụng cho đến khi bản phát hành tiếp theo được xuất bản.

Tôi hy vọng điều này sẽ cho ai đó hiểu rõ hơn về cách thức loại phiên bản này (hoặc nên) hoạt động. Đối với tôi, đó là định nghĩa và thực tiễn duy nhất làm cho bất kỳ loại ý nghĩa thực sự nào khi sử dụng loại phiên bản này.

Tôi chỉ từng thấy một số bản dựng là số cuối cùng trong ID phát hành. Tôi không chắc chắn làm thế nào bạn đưa ra một bản sửa đổi cho một số bản dựng. Tôi cho rằng nếu bạn đã thay đổi một số tài nguyên không được xây dựng (biểu tượng, tập lệnh DB, v.v.), có thể, nhưng hầu hết các dự án tôi đã làm gần đây đều có tất cả những thứ đó dưới sự kiểm soát phiên bản, vì vậy quá trình xây dựng sẽ chọn chúng khi làm cho trình cài đặt / phát hành. Tôi thích số bản dựng có dấu thời gian, mặc dù không hoàn toàn như @David mô tả (tôi thích Major.minor.revision.HHMM). Tuy nhiên, nơi tôi làm việc, chúng tôi chỉ sử dụng một số tuần tự mà máy chủ xây dựng của chúng tôi tạo ra.

Giống như jkohlhepp, chúng tôi sử dụng phần thứ ba của phiên bản để hiển thị số sửa đổi trong SubVersion và phần thứ tư để hiển thị số bản dựng từ máy chủ tích hợp liên tục của chúng tôi (Jenkins cho chúng tôi). Điều này mang lại cho chúng tôi một số lợi ích - có số phiên bản được đặt bởi máy chủ CI của chúng tôi sẽ loại bỏ một bước thủ công có thể vô tình bị bỏ qua; thật dễ dàng để kiểm tra xem nhà phát triển đã không thực hiện một bản phát hành táo bạo từ PC phát triển của họ (điều này sẽ dẫn đến những con số này bằng không); và nó cho phép chúng ta buộc bất kỳ phần mềm nào trở lại cả mã mà nó được tạo ra và công việc CI đã tạo ra nó, chỉ bằng cách nhìn vào số phiên bản - đôi khi chúng ta thấy rất hữu ích.

Đó là bất cứ điều gì bạn muốn nó được. Tôi có xu hướng sử dụng year.month.day.hhmm cho chuyên ngành của mình.minor.build.revision. Nếu tôi sản xuất nhiều hơn một phút, có gì đó không đúng. bạn chỉ có thể sử dụng một mức tăng đơn giản, hoặc tôi đã thấy một số máy phát công phu cho chúng. Làm gì bạn muốn nó được. Những gì họ cần làm là làm cho nó để bạn có được nguồn được sử dụng để tạo đầu ra đó, vì vậy bất cứ điều gì cho phép bạn làm điều đó.

Hai chữ số cuối cùng là tổng số bản dựng

1.01.2.1234

số bản dựng là 2.1234 tuy nhiên hầu hết mọi người sẽ chỉ sử dụng 1234 do phần 2 không thay đổi thường xuyên.

Nhóm của chúng tôi sử dụng số thứ ba (sửa đổi) làm số sửa đổi từ kho Subversion. Chúng tôi sử dụng số thứ tư (bản dựng) làm số bản dựng từ máy chủ tích hợp liên tục TeamCity của chúng tôi, thứ thực sự tạo ra bản dựng. TeamCity tạo một tệp lắp ráp mới với số # bên phải trong quá trình xây dựng.