git, maven và jenkins - phiên bản, dev và phát hành xây dựng quy trình công việc


12

Cách ưa thích để làm như sau với git, maven và jenkins:

Tôi đang phát triển một ứng dụng mà tôi muốn duy trì các nhánh "dev" và "phát hành". Tôi muốn jenkins xây dựng cả hai. Có thể là do các tạo phẩm phát hành sẽ có các phiên bản như 1.5.2 và các bản dựng dev sẽ chỉ là 0.0.1-SNAPSHOT. Tôi muốn không phải có 2 tệp pom.xml khác nhau.

Tôi đã xem xét hồ sơ, nhưng dường như họ không thể thay đổi các phiên bản giả. Một cách tôi nhìn vào có thể là thêm một 'vòng loại' vào các bản dựng thử nghiệm. Tất nhiên tôi chỉ có thể đổi tên tệp, vì thông tin giả tạo thực sự về điều này không quan trọng, vì ứng dụng này là một ứng dụng độc lập.

Điều gì sẽ là cách ưa thích để làm điều này? Hoặc làm thế nào bạn sẽ làm điều này?

Câu trả lời:


3

Tôi sẽ tưởng tượng nên có một mối quan hệ cố hữu giữa các nhánh này phải giải quyết vấn đề về số phiên bản.

Phát hành

Tôi sẽ hình dung bạn có thể làm một cái gì đó như hợp nhất mã sẵn sàng sản xuất từ ​​nhánh dev sang nhánh phát hành, sau đó thực hiện một bản phát hành Maven (thông qua Jenkins hoặc thủ công). Điều này sẽ tự động cuộn các số phiên bản để xây dựng tiếp theo. Vì vậy, bạn hợp nhất mã 1.4.7-SNAPSHOT cho chi nhánh này, thực hiện việc phát hành và cắt phiên bản 1.4.7 và Maven tự động cuộn bản sao làm việc của bạn thành 1.4.8-SNAPSHOT.

Cập nhật đường cơ sở (tùy chọn)

Nếu bạn chưa sử dụng trung kế của mình (hoặc nhánh cơ sở, v.v.) làm nơi phát hành, bạn nên cập nhật trung kế ngay khi bạn hoàn thành một bản phát hành. Điều này có nghĩa là số phiên bản của bạn cũng đang được cập nhật. Bước này có thể là tranh luận nếu bạn chỉ coi nhánh phát hành là đường cơ sở.

Hợp nhất từ ​​Đường cơ sở đến Chi nhánh Dev

Điều cần thiết là chi nhánh phát triển của bạn luôn cập nhật mã sản xuất thực tế . Bạn cần hợp nhất mã từ đường cơ sở (hoặc nhánh phát hành, tùy thuộc vào việc triển khai) cho đến nhánh phát triển của bạn. Điều này rất quan trọng trong trường hợp của bạn bởi vì nó có nghĩa là những thay đổi của pom xảy ra trong quá trình phát hành, đã thay đổi phiên bản thành 1.4.8-SNAPSHOT, được đưa đến chi nhánh này.


Dựa trên việc đọc tôi đã thực hiện (cũng như các quy trình trong tổ chức của tôi), đây có vẻ là một cách sử dụng khá hiệu quả và hiệu quả của các bản phát hành và ảnh chụp Maven, và thay vì duy trì số phiên bản bị ngắt kết nối hoàn toàn trên các nhánh khác nhau, thật dễ dàng để nói rằng bất kỳ bản dựng 1.4.7-SNAPSHOT nào trên thực tế là tiền thân ngay lập tức của bản phát hành 1.4.7. Chúng có liên quan. Tôi sẽ đi xa hơn để nói rằng nếu bạn không hợp nhất qua lại giữa các chi nhánh này, bạn đang làm sai cả phiên bản SCM và Maven, và bạn có nguy cơ phát triển chống lại mã không khớp với sản xuất , giới thiệu lại lỗi cho sản xuất, vv


Theo "maven phát hành", bạn có nghĩa là plugin maven-release-plugin?
varesa

Vâng. Bạn cũng có thể thiết lập các bản dựng nhất định trong Jenkins thành bản dựng Maven Release, gọi ra plugin maven-release-plugin.
RonU

Điều đó giống như "chìa khóa" đã được tìm kiếm. Cảm ơn!
varesa

1

Suy nghĩ lại cách tiếp cận của bạn.

Nó rất phổ biến để sử dụng, ví dụ 1.4.2 cho phiên bản phát hành và sau đó 1.4.3-SNAPSHOT để phát triển tiếp theo.

Khi bạn cần duy trì việc phát hành 1.4.2 THEN chi nhánh, nó từ cam kết bắt nguồn từ tạo phẩm 1.4.2 của bạn.

Sau đó, bạn nói với Jenkins vị trí của kho lưu trữ của bạn và tên chi nhánh, dẫn đến một tập tin được kiểm tra, và sau đó bạn nói với Jenkins sử dụng maven trên dự án của bạn để xây dựng nó.

Lưu ý: Tôi đã thấy rằng rất có lợi khi sử dụng một pom.xml duy nhất để xây dựng tạo phẩm thực tế và một pom.xml khác để tạo các bit thực tế để đến với khách hàng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.