Trang này trình bày về các hệ thống xây dựng dựa trên tác vụ, cách hoạt động của các hệ thống này và một số vấn đề có thể xảy ra với các hệ thống dựa trên tác vụ. Sau tập lệnh shell, hệ thống xây dựng dựa trên tác vụ là bước phát triển logic tiếp theo của quá trình xây dựng.
Tìm hiểu về hệ thống xây dựng dựa trên tác vụ
Trong hệ thống xây dựng dựa trên tác vụ, đơn vị công việc cơ bản là tác vụ. Mỗi tác vụ là một tập lệnh có thể thực thi bất kỳ loại logic nào và các tác vụ chỉ định các tác vụ khác dưới dạng phần phụ thuộc phải chạy trước các tác vụ đó. Hầu hết các hệ thống xây dựng chính đang được sử dụng hiện nay, chẳng hạn như Ant, Maven, Gradle, Grunt và Rake, đều dựa trên tác vụ. Thay vì tập lệnh shell, hầu hết các hệ thống xây dựng hiện đại đều yêu cầu kỹ sư tạo tệp bản dựng mô tả cách thực hiện quá trình tạo bản dựng.
Hãy lấy ví dụ này từ Hướng dẫn sử dụng Kiến trúc:
<project name="MyProject" default="dist" basedir=".">
<description>
simple example build file
</description>
<!-- set global properties for this build -->
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
description="compile the source">
<!-- Compile the Java code from ${src} into ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
description="generate the distribution">
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"/>
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean"
description="clean up">
<!-- Delete the ${build} and ${dist} directory trees -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>
Tệp bản dựng được viết bằng XML và xác định một số siêu dữ liệu đơn giản về bản dựng cùng với danh sách tác vụ (thẻ <target> trong XML). (Kiến sử dụng từ
target để biểu thị một công việc và sử dụng từ công việc để chỉ
lệnh.) Mỗi nhiệm vụ sẽ thực thi một danh sách các lệnh khả thi do Ant xác định,
Thao tác này bao gồm việc tạo và xoá các thư mục, chạy javac và
tạo một tệp JAR. Nhóm lệnh này có thể được mở rộng bằng các trình bổ trợ do người dùng cung cấp để bao gồm mọi loại logic. Mỗi tác vụ cũng có thể xác định các tác vụ mà tác vụ đó phụ thuộc vào thông qua thuộc tính depends. Các phần phụ thuộc này tạo thành một biểu đồ không tuần hoàn, như trong Hình 1.
Hình 1. Biểu đồ không tuần hoàn cho thấy các phần phụ thuộc
Người dùng thực hiện bản dựng bằng cách cung cấp nhiệm vụ cho công cụ dòng lệnh của Ant. Ví dụ:
khi người dùng nhập ant dist, Ant sẽ thực hiện các bước sau:
- Tải tệp có tên
build.xmltrong thư mục hiện tại và phân tích cú pháp tệp đó để tạo cấu trúc biểu đồ như minh hoạ trong Hình 1. - Tìm tác vụ có tên
distđược cung cấp trên dòng lệnh và phát hiện tác vụ này có phần phụ thuộc trên tác vụ có têncompile. - Tìm tác vụ có tên
compilevà phát hiện tác vụ này có một phần phụ thuộc trên tác vụ có têninit. - Tìm tác vụ có tên
initvà phát hiện tác vụ không có phần phụ thuộc. - Thực thi các lệnh được xác định trong tác vụ
init. - Thực thi các lệnh được xác định trong tác vụ
compiledựa trên tất cả các lệnh đó các phần phụ thuộc của tác vụ đã được chạy. - Thực thi các lệnh được xác định trong tác vụ
dist, với điều kiện là tất cả phần phụ thuộc của tác vụ đó đã được chạy.
Cuối cùng, mã do Ant thực thi khi chạy tác vụ dist tương đương với tập lệnh shell sau:
./createTimestamp.shmkdir build/javac src/* -d build/mkdir -p dist/lib/jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*
Khi cú pháp bị xoá, tệp bản dựng và tập lệnh bản dựng thực sự sẽ bị xoá
không quá khác biệt. Nhưng chúng tôi đã thu được rất nhiều lợi ích nhờ việc này. Chúng ta có thể tạo các tệp bản dựng mới trong các thư mục khác và liên kết các tệp đó với nhau. Chúng tôi có thể dễ dàng
thêm các công việc mới phụ thuộc vào các công việc hiện có theo cách tuỳ ý và phức tạp. T4
chỉ cần chuyển tên của một công việc vào công cụ dòng lệnh ant và công cụ này
xác định mọi thứ cần chạy.
Ant là một phần mềm cũ, được phát hành lần đầu vào năm 2000. Các công cụ khác như Maven và Gradle đã cải thiện Ant trong những năm qua và về cơ bản đã thay thế nó bằng cách thêm các tính năng như tự động quản lý các phần phụ thuộc và cú pháp rõ ràng hơn mà không cần XML. Tuy nhiên, bản chất của những quảng cáo này hệ thống vẫn giữ nguyên: chúng cho phép kỹ sư viết tập lệnh bản dựng theo theo nguyên tắc và theo mô-đun thành các nhiệm vụ, đồng thời cung cấp các công cụ để thực hiện các nhiệm vụ đó cũng như quản lý các phần phụ thuộc.
Mặt tối của hệ thống xây dựng dựa trên tác vụ
Về cơ bản, các công cụ này cho phép kỹ sư xác định bất kỳ tập lệnh nào dưới dạng một tác vụ, vì vậy, các công cụ này cực kỳ mạnh mẽ, cho phép bạn làm được hầu hết mọi việc mà bạn có thể tưởng tượng. Tuy nhiên, sức mạnh đó cũng đi kèm với những hạn chế và hệ thống xây dựng dựa trên tác vụ có thể trở nên khó sử dụng khi tập lệnh bản dựng của chúng trở nên phức tạp hơn. Vấn đề với các hệ thống như vậy là cuối cùng chúng lại cấp quá nhiều quyền cho kỹ sư và không đủ quyền cho hệ thống. Vì hệ thống không biết các tập lệnh đang làm gì, nên hiệu suất bị ảnh hưởng, vì hệ thống phải rất thận trọng trong cách lập lịch và thực thi các bước xây dựng. Và không có cách nào để hệ thống xác nhận rằng mỗi tập lệnh đang hoạt động đúng cách, vì vậy, các tập lệnh có xu hướng và trở thành một việc khác cần được gỡ lỗi.
Khó khăn khi chạy song song các bước xây dựng
Các máy trạm phát triển hiện đại khá mạnh mẽ, với nhiều nhân có thể thực thi song song một số bước xây dựng. Tuy nhiên, các hệ thống dựa trên tác vụ thường không thể thực thi tác vụ song song ngay cả khi có vẻ như chúng có thể thực hiện được. Giả sử tác vụ A phụ thuộc vào tác vụ B và C. Vì nhiệm vụ B và C không phụ thuộc lẫn nhau, liệu có an toàn khi chạy đồng thời hai định dạng này không để hệ thống có thể chuyển sang tác vụ A nhanh hơn? Có thể, nếu họ không chạm vào bất kỳ cùng một tài nguyên. Nhưng có thể không – có thể cả hai đều sử dụng cùng một tệp để theo dõi trạng thái và việc chạy đồng thời các tệp đó sẽ gây ra xung đột. Nhìn chung, hệ thống không có cách nào để biết được điều này, vì vậy, hệ thống phải chấp nhận rủi ro về những xung đột này (dẫn đến các vấn đề về bản dựng hiếm gặp nhưng rất khó gỡ lỗi) hoặc phải hạn chế toàn bộ bản dựng chạy trên một luồng trong một quy trình. Điều này có thể gây lãng phí rất lớn cho máy tính mạnh của nhà phát triển và loại trừ hoàn toàn khả năng phân phối bản dựng trên nhiều máy.
Khó tạo bản dựng tăng dần
Một hệ thống xây dựng tốt cho phép các kỹ sư tạo các bản dựng gia tăng đáng tin cậy, chẳng hạn như một thay đổi nhỏ không yêu cầu phải tạo lại toàn bộ cơ sở mã từ đầu. Điều này đặc biệt quan trọng nếu hệ thống xây dựng bị chậm và không thể song song hoá các bước xây dựng vì những lý do nêu trên. Nhưng thật không may, hệ thống xây dựng dựa trên tác vụ cũng gặp khó khăn ở đây. Vì các tác vụ có thể làm bất cứ điều gì, nên nói chung, không có cách nào để kiểm tra xem các tác vụ đó đã được thực hiện hay chưa. Nhiều tác vụ chỉ cần lấy một tập hợp tệp nguồn và chạy trình biên dịch để tạo một tập hợp tệp nhị phân; do đó, bạn không cần chạy lại các tác vụ đó nếu các tệp nguồn cơ bản không thay đổi. Tuy nhiên, nếu không có thông tin bổ sung thì hệ thống sẽ không thể nói như vậy chắc chắn – có thể nhiệm vụ sẽ tải xuống một tệp có thể đã thay đổi hoặc có thể ghi dấu thời gian có thể khác nhau trong mỗi lần chạy. Để đảm bảo tính chính xác, hệ thống thường phải chạy lại mọi tác vụ trong mỗi bản dựng. Một số hệ thống xây dựng cố gắng bật các bản dựng gia tăng bằng cách cho phép kỹ sư chỉ định các điều kiện cần chạy lại một tác vụ. Đôi khi, việc này là khả thi, nhưng thường thì đây là một vấn đề phức tạp hơn nhiều so với vẻ bề ngoài. Ví dụ: trong các ngôn ngữ giống như C++ cho phép các tệp được đưa trực tiếp vào tệp khác, không thể xác định toàn bộ tập hợp tệp phải được theo dõi để biết các thay đổi mà không cần phân tích cú pháp nguồn đầu vào. Các kỹ sư thường sử dụng lối tắt và những lối tắt này có thể dẫn đến các vấn đề hiếm gặp và khó chịu, trong đó kết quả của một tác vụ được sử dụng lại ngay cả khi không nên. Khi điều này xảy ra thường xuyên, các kỹ sư sẽ có thói quen chạy sạch trước mỗi bản dựng để có trạng thái mới, đánh bại hoàn toàn mục đích của việc có một bản dựng tăng dần trong phiên bản đầu tiên địa điểm. Việc xác định thời điểm cần chạy lại một tác vụ là việc rất khó và khó thực hiện công việc do máy móc xử lý tốt hơn con người.
Khó duy trì và gỡ lỗi tập lệnh
Cuối cùng, các tập lệnh bản dựng do hệ thống bản dựng dựa trên tác vụ áp đặt thường rất khó sử dụng. Mặc dù thường ít được kiểm tra kỹ lưỡng hơn, nhưng tập lệnh bản dựng cũng là mã giống như hệ thống đang được tạo và là nơi dễ ẩn lỗi. Sau đây là một số ví dụ về những lỗi rất phổ biến khi làm việc với hệ thống xây dựng dựa trên nhiệm vụ:
- Tác vụ A phụ thuộc vào tác vụ B để tạo một tệp cụ thể làm đầu ra. Chủ sở hữu của nhiệm vụ B không nhận ra rằng các nhiệm vụ khác dựa vào nhiệm vụ đó, vì vậy họ thay đổi nó thành sản xuất ở một vị trí khác. Bạn không thể phát hiện điều này cho đến khi có người cố gắng chạy tác vụ A và nhận thấy tác vụ đó không thành công.
- Tác vụ A phụ thuộc vào tác vụ B, tác vụ B phụ thuộc vào tác vụ C, tác vụ C đang tạo một tệp cụ thể làm đầu ra mà tác vụ A cần. Chủ sở hữu của tác vụ B quyết định rằng tác vụ này không cần phụ thuộc vào tác vụ C nữa, điều này khiến tác vụ A không thành công mặc dù tác vụ B hoàn toàn không quan tâm đến tác vụ C!
- Nhà phát triển của một công việc mới vô tình đưa ra giả định về máy chạy tác vụ, chẳng hạn như vị trí của công cụ hoặc giá trị của các biến môi trường cụ thể. Tác vụ hoạt động trên máy của họ nhưng không thành công mỗi khi một nhà phát triển khác thử.
- Một tác vụ chứa một thành phần không xác định, chẳng hạn như tải tệp xuống từ Internet hoặc thêm dấu thời gian vào một bản dựng. Giờ đây, mọi người có thể nhận được kết quả khác nhau mỗi khi chạy bản dựng, nghĩa là các kỹ sư không phải lúc nào cũng có thể tái tạo và khắc phục lỗi của nhau hoặc lỗi xảy ra trên hệ thống xây dựng tự động.
- Các tác vụ có nhiều phần phụ thuộc có thể tạo ra tình huống tương tranh. Nếu tác vụ A phụ thuộc vào cả tác vụ B và tác vụ C, đồng thời tác vụ B và C đều sửa đổi cùng một tệp, thì tác vụ A sẽ nhận được kết quả khác nhau tuỳ thuộc vào việc tác vụ nào trong số tác vụ B và C hoàn tất trước.
Không có cách chung để giải quyết các vấn đề về hiệu suất, độ chính xác hoặc khả năng bảo trì trong khung dựa trên tác vụ được trình bày ở đây. Rất lâu vì các kỹ sư có thể viết mã tuỳ ý chạy trong quá trình tạo bản dựng, nên hệ thống không thể có đủ thông tin để luôn có thể chạy các bản dựng một cách nhanh chóng và chính xác. Để giải quyết vấn đề này, chúng ta cần lấy một số quyền ra khỏi tay kỹ sư và đưa quyền đó trở lại hệ thống, đồng thời tái cấu trúc vai trò của hệ thống không phải là chạy tác vụ mà là tạo cấu phần phần mềm.
Phương pháp này dẫn đến việc tạo ra các hệ thống xây dựng dựa trên cấu phần phần mềm, chẳng hạn như Blaze và Bazel.