về chúng tôi
Tại 1C, chúng tôi không chỉ phát triển nền tảng trên и , mà cả các ứng dụng Java - đặc biệt là môi trường phát triển mới dựa trên Eclipse và máy chủ nhắn tin được tích hợp sâu với nền tảng - .
Nhập
Chúng tôi thường sử dụng maven làm hệ thống xây dựng cho các ứng dụng Java và trong bài viết ngắn này, chúng tôi muốn nói về một trong những vấn đề mà chúng tôi gặp phải trong quá trình tổ chức phát triển và về cách tiếp cận cho phép chúng tôi khắc phục vấn đề này vấn đề.
Điều kiện tiên quyết và quy trình làm việc
Do đặc thù phát triển trong các dự án maven của chúng tôi, chúng tôi sử dụng khá nhiều mô-đun, phần phụ thuộc và các dự án con. Số lượng tệp pom trong một cây có thể lên tới hàng chục hoặc thậm chí hàng trăm.
Có vẻ như: không có gì to tát, họ đã tạo ra nó một lần và quên mất nó. Nếu bạn cần thay đổi hoặc thêm nội dung nào đó vào tất cả các tệp cùng một lúc, có rất nhiều công cụ tiện lợi trong trình chỉnh sửa và IDE. Thay đổi thường xuyên nhất đối với pom.xml là gì? Chúng tôi tin rằng những thay đổi trong phiên bản dự án và các phần phụ thuộc. Có lẽ ai đó sẽ muốn tranh luận về điều này, nhưng đây chính xác là tình huống của chúng tôi. Lý do nằm ở chỗ, cùng với kernel, chúng tôi đang đồng thời phát triển nhiều thư viện của riêng mình và để có khả năng tái tạo liên tục các kết quả xây dựng và thử nghiệm, việc sử dụng ảnh chụp nhanh đối với chúng tôi dường như không phải là một cách tiếp cận thuận tiện. Vì lý do này, cần phải tăng số phiên bản trong các dự án với mỗi bản dựng.
Ngoài ra, đôi khi, nhà phát triển cần xây dựng nhánh thư viện của riêng mình và kiểm tra chức năng của nó dựa trên tất cả các phần phụ thuộc, do đó anh ta phải thay đổi phiên bản của tất cả chúng theo cách thủ công.
Giải pháp ban đầu
Với những thay đổi thường xuyên và nhiều phiên bản như vậy, tôi muốn đơn giản hóa và tự động hóa quy trình trong CI. Đây là lúc một plugin tiện lợi, nổi tiếng xuất hiện để giải cứu. phiên bản-maven-plugin - kết nối nó và khởi chạy nó
phiên bản mvn -N:set -DnewVersion=2.0.1
và Maven sẽ làm mọi thứ như bình thường: nó sẽ chạy qua hệ thống phân cấp từ trên xuống dưới, thay thế tất cả các phiên bản - vẻ đẹp! Bây giờ tất cả những gì còn lại là đưa ra yêu cầu kéo, đồng nghiệp sẽ xem xét các thay đổi và bạn có thể nhanh chóng tham gia vào đường trục. Nhanh chóng? Dù thế nào đi chăng nữa. Một vài trăm pom.xml để xem xét và đây không phải là tính mã. Ngoài ra, không ai an toàn trước những xung đột khi hợp nhất với số lượng lớn tệp bị thay đổi như vậy. Cần lưu ý ở đây rằng trong quy trình CI, các thay đổi phiên bản diễn ra tự động cùng với những thay đổi về chức năng chứ không phải riêng biệt theo cách nào đó.
Các tính năng mới
Chúng tôi bình tĩnh lại được một lúc và cam chịu, chúng tôi sống như vậy cho đến khi những người từ Bắt đầu từ phiên bản 3.5.0-beta-1, Maven không hỗ trợ cái gọi là “giữ chỗ”. Bản chất của những sự thay thế này là pom.xml thay vì chỉ dẫn cụ thể về phiên bản dự án, các biến được sử dụng ${sửa đổi}, ${sha1} и ${danh sách thay đổi}. Bản thân các giá trị của các thuộc tính này được đặt trong phần tửtài sản> hoặc chúng có thể được xác định thông qua thuộc tính hệ thống
mvn -Drevision=2.0.0 gói sạch
Giá trị thuộc tính hệ thống được ưu tiên hơn các giá trị được xác định trongtài sản>.
Cha mẹ
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-cha mẹ
Thân thiện với CI đầu tiên
${revision}${sha1}${changelist}
...
1.3.1
-CHỤP ẢNH
Con cháu
4.0.0
org.apache.maven.ci
ci-cha mẹ
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-con
...
Nếu bạn muốn xây dựng phiên bản 2.0.0-SNAPSHOT thì chỉ cần sử dụng
mvn -Drevision=2.0.0 gói sạch
Nếu bạn muốn phát hành thì chỉ cần đặt lại SNAPSHOT
mvn -Dchangelist= gói sạch
*Các ví dụ trên được lấy từ trên trang web Dự án Maven Apache
Thực tế khắc nghiệt
Mọi thứ đều tốt đẹp và lành mạnh, đã đến lúc cảm thấy hài lòng nhưng không. Hóa ra phương pháp này sẽ không hiệu quả để cài đặt và triển khai, vì nó sẽ không được thay thế trong mô tả về các tạo phẩm được xuất bản trong kho lưu trữ ${sửa đổi} về ý nghĩa của nó và maven sẽ không còn hiểu nó là gì nữa.
org.apache
apache
${sửa đổi}
Một ánh sáng cuối đường hầm
Chúng ta cần tìm kiếm giải pháp cho vấn đề. Có thể đã cứu được tình hình . Plugin này giải quyết tất cả các biến trong pom, nhưng đồng thời cắt bỏ nhiều thông tin khác chỉ cần trong quá trình lắp ráp và không cần thiết khi nhập các tạo phẩm đã xuất bản vào các dự án khác. Plugin này cũng “làm rõ” tất cả các phần phụ thuộc cha-con và kết quả là bạn sẽ có được một pom phẳng bao gồm mọi thứ bạn cần. Điều bất tiện là nó cắt bỏ quá nhiều phần “thừa”, điều này không phù hợp với chúng tôi chút nào. Sau khi nghiên cứu thông tin về quá trình phát triển plugin này, hóa ra chúng tôi không phải là người duy nhất trong vũ trụ và trở lại vào tháng 2018 năm 1.1.0, một yêu cầu kéo đã được tạo trên Github trong kho plugin với mong muốn biến điều đó thành hiện thực để tự mình xác định cách “làm hỏng” pom.xml. Các nhà phát triển đã lắng nghe tiếng nói của những người đau khổ, và vào tháng XNUMX, với việc phát hành phiên bản mới XNUMX, một chế độ mới, ResolveCiFriendliesOnly, đã xuất hiện trong plugin Flat-maven, phù hợp hơn bao giờ hết - nó rời đi pom.xml nguyên trạng, ngoại trừ phần tử và cho phép ${sửa đổi}, ${sha1} и ${danh sách thay đổi}.
Thêm plugin vào dự án
org.codehaus.mojo
làm phẳng-maven-plugin
1.1.0
ĐÚNG VẬY
giải quyếtCiFriendliesOnly
làm phẳng
tài nguyên quy trình
làm phẳng
làm phẳng.clean
lau dọn
lau dọn
Xong!
Kết cuộc hạnh phúc
Từ giờ trở đi, để thay đổi phiên bản của toàn bộ dự án và cho tất cả các phụ thuộc biết về nó, chúng ta chỉ cần chỉnh sửa phần tửsửa đổi> chỉ trong thư mục gốc pom.xml. Không phải một hoặc hai tệp trong số này có cùng một thay đổi sẽ được đưa vào đánh giá mà chỉ có một. Thôi, không cần dùng đâu phiên bản-maven-plugin.
Nguồn: www.habr.com