2013-08-12 28 views
5

Chúng tôi hiện đang phát triển một ứng dụng có nhiều luồng phát triển song song. Chúng tôi có một công việc Jenkins để xây dựng mỗi luồng/phát hành. Vì vậy, Job-A có thể đang xây dựng bản phát hành 1.1 và Job-B có thể đang phát hành phiên bản 1.2.Jenkins chia sẻ số lượng xây dựng qua các công việc?

Tôi nghĩ tốt nhất nên có số bản dựng được chia sẻ trên mỗi bản phát hành, nếu Job-A chạy với số bản dựng 125, nếu Job-B chạy tiếp theo nó sẽ chạy với số xây dựng 126. Lý do tôi nghĩ đây là chiến lược tốt nhất là đây là ứng dụng Android, yêu cầu tham số versionCode của nó được tăng lên mỗi khi được gửi tới Google Play. Chúng tôi sử dụng số xây dựng Jenkins cho giá trị versionCode.

Có cách nào để định cấu hình Jenkins để chia sẻ số bản dựng trên nhiều công việc không? Hoặc, có ai đưa ra giải pháp tốt hơn cho vấn đề này không?

+1

có thể trùng lặp với http://stackoverflow.com/questions/17429061/how-to-convince-jenkins-to-share-a-build-number-for-several-jobs – dnozay

Trả lời

0

@coffeebreaks cung cấp một phản ứng tuyệt vời, nhưng chúng tôi đã kết thúc viết một plugin tùy chỉnh mà cho phép việc chia sẻ một số build nếu tên công việc có tiền tố phù hợp.

+3

Bạn có xuất bản plugin này không? Tôi sẽ quan tâm đến việc sử dụng một cái gì đó tương tự. –

+1

Câu trả lời này là vô ích – Liam

4

câu trả lời ngắn sử dụng dấu thời gian hoặc đặt mã phiên bản theo cách thủ công, giữ mọi thứ ra khỏi máy chủ CI khi không cần thiết. Hoặc buộc các số jenkins xây dựng.

câu trả lời dài Tôi thích jenkins chịu trách nhiệm tự động hóa điều gì đó cũng hoạt động độc lập. Vì vậy, nếu tôi không cần jenkins cho việc thiết lập, tôi cũng hạnh phúc.

Ngoài ra nếu bạn sử dụng 2 chi nhánh, bạn có thể cam kết theo thứ tự ngẫu nhiên vào chúng. Cố gắng kết hợp các công việc với nhau theo một số cách có vẻ như một rắc rối không cần thiết có thể là một vấn đề sau này. Ví dụ. nếu phiên bản 2.0 được xây dựng và QAed bây giờ, chỉ cần chờ đợi ngày phát hành thích hợp và nhóm tiếp thị để hoàn thành công việc của mình, nhưng bạn cần phải phát hành bản sửa lỗi nhanh v1.1.1 sau đó? Tùy thuộc vào giải pháp bạn chọn, bạn có thể cần phải kích hoạt một số công cụ xây dựng lại để buộc một sự bẻ khóa versionCode. Xây dựng mới, QA mới?

Yêu cầu thực sự của bạn đối với versionCode là nó cao hơn phiên bản trước đó.

Từ http://developer.android.com/guide/topics/manifest/manifest-element.html

android: Mã phiên bản Một số phiên bản nội bộ.

Số này được sử dụng chỉ để xác định xem một phiên bản có gần đây hơn phiên bản khác không, với số cao hơn cho biết các phiên bản gần đây hơn. Đây không phải là số phiên bản được hiển thị cho người dùng; số đó được đặt bởi thuộc tính versionName . Giá trị phải được đặt làm số nguyên, chẳng hạn như "100". Bạn có thể xác định nó theo bất kỳ cách nào bạn muốn, miễn là mỗi phiên bản liên tiếp có số cao hơn . Ví dụ, nó có thể là một số xây dựng. Hoặc bạn có thể dịch số phiên bản ở định dạng "x.y" thành số nguyên bằng cách mã hóa riêng "x" và "y" ở 16 bit trên và dưới. Hoặc bạn chỉ đơn giản có thể tăng số một mỗi lần một phiên bản mới được phát hành .

Vì vậy, đây là 2 giải pháp:

  • thủ công năng đẩy. Trong các dự án của chúng tôi, tôi sử dụng một số tập lệnh sed để tự động hóa sự va chạm của số bản dựng trước khi phát hành. Vì tôi cũng cần phải thay đổi một vài thứ bằng tay, như tiền tố versionName, vô hiệu hóa/bật chế độ gỡ lỗi trong khi phát triển, v.v., tôi chạy tập lệnh bumpversion theo cách thủ công để phiên bản tiếp theo trong nhánh của tôi có số phiên bản và mã phiên bản thích hợp. Lưu ý tôi sử dụng số jenkins build trong versionName để thay thế. Giải pháp này ngăn bạn có 1.1.1 cần phải được ra sau khi v2 đã sẵn sàng vấn đề nếu bạn chọn một bump phiên bản đủ lớn cho v2.

  • giải pháp tự động hóa khác nhưng vẫn đơn giản hơn là sử dụng thứ gì đó ngoài dấu thời gian. Định dạng YYMMDDHHSS là đủ tốt của một số nguyên (< 2^31), và rất có thể là bất kỳ phiên bản nào bạn sắp phát hành tiếp theo sẽ được chuẩn bị sau phiên bản trước và không phải trong cùng một phút. Vì vậy, về cơ bản khi bạn tạo phiên bản v1.1, nó sẽ đạt được 1308131600 và nếu bạn xây dựng v1.2 phút sau khi nó được 1308131601. (điều này rõ ràng là không giúp bạn chống lại kịch bản v1.1.1/v2)

Dưới đây là một số ý tưởng cho các kịch bản để tạo/cập nhật mã phiên bản Auto increment version code in Android app.

The Jenkins cách

Bây giờ nếu bạn vẫn muốn Jenkins phụ trách, một giải pháp đơn giản là sử dụng một cái gì đó giống như https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin và cấu hình của bạn việc làm mỗi chi nhánh có một tiền tố đủ lớn để đảm bảo không đụng độ. Các thiết lập vẫn còn khá đơn giản.

Ví dụ:

  • 110000 cho chi nhánh 1.1
  • 120000 cho chi nhánh 1,2
+0

Cảm ơn bạn đã phản hồi kỹ lưỡng. Điểm của bạn là tất cả các tùy chọn hợp lệ cho bất kỳ ai khác có cùng câu hỏi. –

0

Tôi chưa thử, nhưng tôi đang nghĩ đến việc xây dựng máy và trong mỗi công việc thay thế tệp nextBuildNumber bằng liên kết tượng trưng tới một tệp duy nhất ở đâu đó. Cái gì có thể đi sai. Vâng, truy cập đồng thời có thể là một vấn đề. Có thể có vấn đề nếu Jenkins tạo lại tệp từ đầu, tức là bằng cách xóa và tạo, thay vì chỉ mở nó như bình thường.

Các vấn đề liên quan