Trong những năm lập trình Java và gần đây là Scala, tôi chưa bao giờ sử dụng Ant, Maven, Gradle hoặc bất kỳ công cụ xây dựng nào cho Java. Ở mọi nơi tôi từng làm việc, có một người quản lý xây dựng đã lo tất cả những điều đó - Tôi đã biên dịch cục bộ với IDE để phát triển và thử nghiệm đơn vị, sau đó kiểm tra mã nguồn và thông báo cho người quản lý xây dựng đã làm những gì cần thiết để biên dịch các tập tin của mọi người cho môi trường chia sẻ.

Bây giờ tôi đang ở giữa các hợp đồng tôi đã làm việc cho dự án tự tài trợ của chính mình và nó đang đi đến điểm có thể đủ tốt để thực sự kiếm tiền. Tôi thậm chí có một nhà đầu tư tiềm năng xếp hàng và dự định cho họ xem phiên bản beta trong vài tuần tới.

Nhưng tất cả cùng tôi chỉ cần nhấp vào nút xây dựng trên IDE và nó tạo tệp Jar và nó hoạt động tốt. Tất nhiên, sự khôn ngoan thông thường cho thấy rằng tôi "nên" viết kịch bản Ant / Maven / Gradle của riêng mình và sử dụng nó thay vì IDE, nhưng những lợi thế cụ thể của điều đó trong tình huống của tôi (làm việc một mình) là gì?

Tôi đã đọc một số cách đọc về cách sử dụng các công cụ xây dựng đó và có vẻ như tôi đang viết hàng trăm dòng XML (hoặc Groovy hoặc bất cứ thứ gì) để làm những gì IDE làm trong một cú nhấp chuột (do IDE tạo ra Ant XML cho dự án là hơn 700 dòng). Nó chỉ có vẻ dễ bị lỗi và tốn thời gian và không cần thiết cho tình huống của tôi. Không đề cập đến đường cong học tập, sẽ lấy đi thời gian từ tất cả các công việc khác mà tôi đang làm để sản phẩm sẵn sàng cho mọi người thấy.

Tôi khuyên bạn nên xem xét sử dụng Maven trái ngược với Ant. Nếu IDE của bạn có thể xây dựng dự án của bạn chỉ bằng một cú nhấp chuột, thì có khả năng Maven cũng có thể xây dựng dự án của bạn mà hầu như không có cấu hình tùy chỉnh.

Và để trả lời câu hỏi, đơn giản hóa quá trình triển khai là một ví dụ cụ thể. Nếu bạn đang xây dựng một bản phân phối cục bộ có nghĩa là bạn phải triển khai thủ công phân phối đó trên hệ thống sản xuất của mình và ngụ ý rằng bạn có thể phải thực hiện một chút cấu hình thủ công trên hệ thống sản xuất để sẵn sàng triển khai (cài đặt Tomcat , có lẽ, hoặc sao chép qua các phụ thuộc và tài nguyên theo yêu cầu của ứng dụng của bạn). Điều này có thể tốn thời gian và có thể làm cho việc triển khai các bản cập nhật trở thành một quy trình thủ công, tẻ nhạt. Nó cũng cho phép tiềm năng cho bất kỳ sự khác biệt nhỏ về cấu hình giữa nền tảng sản xuất và môi trường phát triển của bạn để gây ra các lỗi tối nghĩa, khó theo dõi.

Vì vậy, dù sao đi nữa, điều tôi làm để thoát khỏi sự vất vả thủ công này là tôi định cấu hình dự án của mình để xây dựng với Maven và tôi định cấu hình pom.xmltệp của mình với tất cả thông tin cần thiết (trong trường hợp ứng dụng web Java) tìm và tải xuống phiên bản chính xác của Tomcat, cài đặt cục bộ, thiết lập các tệp cấu hình Tomcat chính xác, triển khai bất kỳ phụ thuộc dự án nào và chính tệp WAR của dự án, sau đó khởi động Tomcat. Sau đó, tôi tạo một tập lệnh shell đơn giản (và cũng là một .batphiên bản cho Windows) sử dụng Maven để xây dựng và khởi động máy chủ:

mvn clean install cargo:start -Dcargo.maven.wait=true

Vì vậy, thay vì đóng gói có thể triển khai trên môi trường dev của tôi và sau đó tự đẩy nó lên sản xuất, tất cả những gì tôi phải làm là đồng bộ hóa từ hệ thống kiểm soát phiên bản lên máy chủ sản xuất, sau đó hệ thống sản xuất tự xây dựng, cài đặt và chạy có thể triển khai (và thực hiện theo cách giống với cách thực hiện trên bất kỳ hệ thống phát triển nào, giảm thiểu khả năng xảy ra lỗi cụ thể hoặc cấu hình sai nền tảng). Và cho dù trong môi trường phát triển hay sản xuất, tất cả những gì tôi làm để xây dựng và khởi động máy chủ là:

./startServer.sh #or startServer.bat for Windows

Và để triển khai một bản cập nhật cho môi trường sản xuất, quy trình chỉ là:

1. Dừng phiên bản máy chủ đang chạy, nếu có.
2. Chạy đi svn update -r<target_release_revision>.
3. Chạy đi ./startServer.sh.

Thật đơn giản, dễ nhớ và hoàn toàn không thể làm được nếu tôi dựa vào việc sử dụng IDE của mình để xây dựng khả năng triển khai cho tôi. Nó cũng làm cho việc quay trở lại triển khai tốt được biết đến gần đây chỉ trong tích tắc, nên việc quay lại bao giờ là cần thiết.

Tôi thậm chí không thể đếm được lượng thời gian mà phương pháp này đã tiết kiệm cho tôi khi cố gắng tự quản lý quá trình triển khai và cấu hình.

Và tất nhiên, một câu trả lời khác cho câu hỏi của bạn là quản lý phụ thuộc tự động, nhưng tôi tin rằng điều đó đã được bao phủ bởi các câu trả lời khác.

Miễn là mã của bạn nằm trong sự kiểm soát nguồn, sử dụng IDE để làm cho các bản phân phối của bạn là ổn.

Là một người đàn ông, thời gian của bạn tốt hơn dành cho việc thêm các tính năng mới vào sản phẩm của bạn, hoặc viết các tập lệnh xây dựng? Một cái gì đó cho tôi biết nó không viết kịch bản xây dựng.

Chắc chắn, khó hơn để thấy những lợi ích khi bạn làm việc một mình. Cá nhân tôi đã làm việc trong nhiều dự án solo và tôi không chỉ viết kịch bản xây dựng, tôi còn gặp phải rắc rối khi thiết lập Máy chủ CI (như Jenkins).

Tất nhiên là có chi phí, tại sao nó lại có giá trị?

• Bản dựng có thể tái tạo, không bị ràng buộc với IDE (hoặc máy của bạn, nếu bạn chạy bên ngoài). Nếu một máy chủ xây dựng chạy nó, các máy khác có thể chạy nó.
• Cuộc vui bắt đầu sau khi xây dựng và kiểm tra đơn vị (nhân tiện: bạn có chắc là bạn kiểm tra trước mỗi lần cam kết không? Đôi khi tôi quên). Tạo tài liệu, xây dựng trình cài đặt, chạy các công cụ phân tích mã yêu thích của bạn.
• Máy chủ CI yêu thích của bạn cho phép bạn xem các biểu đồ về phạm vi bảo hiểm mã, lỗi kiểm tra đơn vị, v.v. theo thời gian. IDE của bạn có làm điều đó không?

Đối với dự án hiện tại của tôi, tập lệnh xây dựng, chạy các công cụ phân tích tĩnh, nén js / css, kiểm tra đơn vị và các gói vào một kho lưu trữ web. Jenkins chạy nó sau mỗi lần xác nhận và triển khai dự án đến một máy chủ thử nghiệm.

Tôi đã dành thời gian để thiết lập điều này (kịch bản xây dựng có thể là 300 dòng, đã không chạm vào nó trong nhiều tháng) và có thể nói nó đáng giá, ngay cả đối với một người. Đối với nhiều người, điều đó là cần thiết. Sự tham gia của tôi vào quá trình xây dựng / triển khai bao gồm các lệnh "hg commit" và "hg đẩy".

Lợi ích của công cụ xây dựng

Đó là một bản tóm tắt ngắn chỉ hiển thị phần nổi của tảng băng trôi, và bạn sẽ không nhất thiết nhận thấy tầm quan trọng của tất cả những điều này trừ khi bạn cần thực hiện với sự kết hợp của nhiều dự án, dự án lớn và nhóm trung bình đến lớn. Nhưng nếu bạn có niềm tin và cố gắng, bạn sẽ gặt hái được những lợi ích .

Chúng tạo điều kiện cho vòng đời phát triển của bạn và vì chúng cho phép bạn:

• tổ chức và cấu trúc các dự án của bạn một cách nhất quán và dễ dàng
• sử dụng lại các thực tiễn tốt trong các dự án và dễ dàng và nhanh chóng khởi động chúng,
• tích hợp nhiều dự án trong một bản dựng,
• tự động hóa quá trình tích hợp liên tục của bạn ,
• chia sẻ dự án của bạn với người khác
  • mà không ép buộc họ sử dụng bộ công cụ hoặc IDE cụ thể (ngoài hệ thống xây dựng),
  • và không có gì đáng ngạc nhiên khi họ sẽ mong đợi một bản dựng tiêu chuẩn
• tự động hóa và tạo điều kiện cho việc bảo trì sản phẩm của bạn
• tự động hóa quá trình phát hành sản phẩm của bạn

Nếu chúng tôi áp dụng điều này cho Maven ...

Đối với những người trong thế giới Java và những người sử dụng Maven , bằng cách đọc điều này, bạn tự nhiên liên kết từng điểm với:

• Hội nghị dự án có cấu trúc của Maven
• Maven Archetypes
• Vật liệu hóa một dự án từ SCM và các lò phản ứng xây dựng
• Jenkins / Hudson / Bamboo / hỗ trợ khác + Hỗ trợ của Maven cho các hoạt động kiểm tra tích hợp
• m2eclipse, hỗ trợ IntelliJ hoặc NetBeans riêng - hoặc mvnsh cho dòng lệnh
• phiên bản-maven-plugin
• maven-release-plugin, buildnumber-maven-plugin plugin và Phiên bản-maven-plugin

Và tất nhiên, Maven (nhưng cũng là các công cụ khác) cung cấp cho bạn quản lý phụ thuộc và đó là một công cụ tiết kiệm không gian và thời gian rất lớn cho bạn (bao gồm số lượng người trong nhóm của bạn) và SCM của bạn.

Mọi thứ đều tương đối:

Tôi đang sử dụng Maven làm ví dụ vì tôi nghĩ rằng đây là hệ thống xây dựng toàn diện nhất và "bao gồm pin", nhưng điều đó không có nghĩa là nó nhất thiết phải là "tốt nhất". Mặc dù vậy, nó phù hợp với tất cả các tickbox được liệt kê ở trên và khi tìm kiếm một hệ thống xây dựng tốt, tôi so sánh nó với danh sách này và Maven. Tuy nhiên, Maven không phải lúc nào cũng rất linh hoạt - tuy nhiên nó rất có thể mở rộng - nếu bạn đi chệch khỏi quy trình chuẩn hóa của mình. Nó tăng sản phẩm của bạn trong trường hợp chung (một lần đi trước đường cong học tập), không phải nếu bạn chiến đấu với nó.

Dưới đây là 4 lý do hàng đầu của tôi để sử dụng các công cụ xây dựng:

• xử lý phụ thuộc (tránh lỗi)
• kiểm tra (thay đổi của bạn không phá vỡ các mô-đun khác - dễ kiểm tra hơn nhiều)
• cam kết an toàn
• dễ dàng hơn để triển khai phân phối cục bộ (không ai có thời gian trong QA env để chờ người xây dựng xây dựng dự án của bạn và các phụ thuộc của nó)

Trong cuốn sách Lập trình viên thực dụng , Andrew Hunt và David Thomas nói rằng 'thanh toán-xây dựng-thử nghiệm-triển khai' nên là một lệnh duy nhất. (Chương: Dự án thực dụng). Bạn đã viết..

Tôi thậm chí có một nhà đầu tư tiềm năng xếp hàng và dự định cho họ xem phiên bản beta trong vài tuần tới

Sau đó, tôi chắc chắn rằng nhóm của bạn sẽ phát triển .. Điều quan trọng hơn nữa là phải thực hiện các khả năng triển khai thử nghiệm tự động.

XML (tập lệnh) lớn mà bạn đã thấy, thường là công việc một lần. Hầu hết thời gian, các kịch bản tương tự có thể được sử dụng trên nhiều dự án.

Không rõ dự án lớn như thế nào. Nếu các bài kiểm tra tích hợp / kiểm tra chấp nhận của bạn chiếm CPU / bộ nhớ lớn, bạn có thể xem xét sử dụng máy khác làm máy chủ thử nghiệm của mình. Bạn cũng có thể triển khai một loạt các công cụ để phân tích mã nguồn / mã byte .

Tôi sẽ lập luận rằng, đối với một nhà phát triển đơn độc, có quy trình và cấu trúc tốt như các bản dựng theo kịch bản là vô cùng quan trọng hơn nhiều so với khi bạn ở trong một nhóm. Lý do là bạn không có đồng đội để gọi bạn khi bạn cắt góc. Một máy chủ CI chạy tập lệnh xây dựng của bạn làm cho một đồng đội tuyệt vời không khoan nhượng để giữ cho bạn trung thực.

Khi cơ sở mã của bạn phát triển, bạn sẽ muốn thêm một bộ kiểm tra. Kinh nghiệm của tôi là việc này nên được thực hiện sớm hơn là muộn hơn và bản dựng hàng đêm (hoặc bất cứ thứ gì) của bạn nên chạy tất cả các bài kiểm tra mỗi lần. Bắt đầu nhỏ, XML được tạo tự động có lẽ là tốt. Khi bạn sợ thay đổi thứ gì đó vì sợ làm hỏng thứ khác, đó là một động lực tốt để viết lên một vài trường hợp thử nghiệm.

Bản dựng không phải IDE giúp dễ dàng xây dựng lại các phiên bản cũ mà không phải lo lắng về việc cấu hình lại IDE của bạn theo thời gian, cho phép bạn thực hiện bản dựng không tương tác để bạn có thể duy trì bản dựng hàng đêm để mọi người kiểm tra hoặc tìm hiểu nhanh nếu bạn đã phá vỡ các bài kiểm tra mà không phải nhớ chạy chúng và chờ đợi chúng hoàn thành.

Nó cũng cho phép bạn thực hiện các bản dựng trong môi trường không phải GUI, ví dụ: chuyển sang máy chủ và cho phép bạn chuyển đổi IDE mà không lo mất khả năng xây dựng phần mềm.

Một số công cụ xây dựng giúp bạn tự động gắn thẻ và triển khai các bản phát hành, đi kèm với các mặc định hợp lý để tạo báo cáo bảo hiểm mã, v.v.

Khi bạn thêm nhiều người, một công cụ xây dựng sẽ đảm bảo bạn không dễ bị tổn thương trước cấu hình IDE kém của người khác. Tôi thường xuyên thực hiện các màn hình để sửa các bản cài đặt Eclipse của đồng nghiệp vì họ không sử dụng các công cụ xây dựng (làm việc trên đó).

Lý do cuối cùng là nó không phải được thực hiện thủ công, vì vậy đừng làm thủ công. Mọi thứ khác rơi ra từ đó.