Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Sau đây là một số tính năng mà bạn có thể tìm thấy trong hầu hết các hệ thống CI.
Môi trường
Điều quan trọng là bạn phải chọn và hiểu rõ môi trường phần cứng và phần mềm mà hệ thống thực thi quy trình công việc. Những điểm quan trọng cần lưu ý đối với ứng dụng Android là:
Nền tảng: Linux, Mac, Windows và phiên bản của các nền tảng này.
Bộ nhớ còn trống: Việc xây dựng ứng dụng và chạy trình mô phỏng có thể sử dụng nhiều RAM. Do đó, bạn thường cần phải điều chỉnh các tham số như kích thước vùng nhớ khối xếp của JVM để tránh các lỗi hết bộ nhớ.
Phần mềm cài đặt sẵn: Các hệ thống CI thường cung cấp hình ảnh chứa một tập hợp lớn các công cụ có sẵn, chẳng hạn như Bộ phát triển Java (JDK), Bộ phát triển phần mềm (SDK) Android, các công cụ bản dựng, nền tảng và trình mô phỏng.
Cấu trúc chạy và tập lệnh: ARM, x86. Điều này rất quan trọng khi
sử dụng trình mô phỏng.
Biến môi trường: Một số do hệ thống CI đặt (ví dụ: ANDROID_HOME) và bạn có thể đặt biến của riêng mình để tránh thông tin xác thực được mã cứng trong quy trình làm việc của mình.
Bạn nên cân nhắc nhiều khía cạnh khác, chẳng hạn như số lượng lõi có sẵn và liệu tính năng ảo hoá có được bật để chạy trình mô phỏng hay không.
Nhật ký và báo cáo
Khi một bước không thành công, hệ thống CI sẽ thông báo cho bạn và thường không cho phép bạn hợp nhất thay đổi đó. Để tìm hiểu xem đã xảy ra sự cố gì, hãy tìm lỗi trong nhật ký.
Ngoài ra, quá trình tạo bản dựng và kiểm thử sẽ tạo ra các báo cáo thường được lưu trữ dưới dạng cấu phần phần mềm của bản dựng cụ thể đó. Tuỳ thuộc vào hệ thống CI, bạn có thể sử dụng các trình bổ trợ để trực quan hoá kết quả của các báo cáo đó.
Thời gian chạy bộ nhớ đệm và CI
Các hệ thống CI sử dụng bộ nhớ đệm bản dựng để tăng tốc quá trình này. Ở hình thức đơn giản nhất, chúng sẽ lưu tất cả các tệp bộ nhớ đệm của Gradle sau khi một bản dựng thành công và khôi phục các tệp đó trước khi tạo một bản dựng mới. Tính năng này dựa trên tính năng bộ nhớ đệm bản dựng của Gradle và bạn nên bật trong dự án.
Sau đây là một số cách giúp cải thiện thời gian chạy và độ tin cậy:
Mô-đun: Phát hiện mô-đun nào bị ảnh hưởng bởi một thay đổi và chỉ tạo và kiểm thử những mô-đun đó.
Bỏ qua bộ nhớ đệm: Nếu bản dựng chứa các tập lệnh mà nhà phát triển đã sửa đổi, hãy bỏ qua bộ nhớ đệm của bản dựng. An toàn hơn khi bạn tạo ứng dụng từ đầu.
Kiểm thử phân đoạn: Đặc biệt là các kiểm thử được đo lường, việc phân đoạn kiểm thử trên nhiều thiết bị có thể hữu ích. Tính năng này được trình chạy Android, Thiết bị do Gradle
quản lý và Phòng thử nghiệm Firebase hỗ trợ.
Bản dựng phân đoạn: Bạn có thể phân đoạn bản dựng trên nhiều phiên bản máy chủ.
Tình trạng không ổn định đề cập đến các quá trình kiểm thử hoặc công cụ không liên tục. Bạn phải luôn cố gắng tìm và khắc phục các vấn đề tạo ra các bản dựng và hoạt động kiểm thử không ổn định, nhưng một số vấn đề trong số đó rất khó tái hiện, đặc biệt là khi chạy kiểm thử đo lường.
Một chiến lược phổ biến là thử chạy lại mỗi khi không thành công, tối đa số lần thử lại.
Không có cách nào để định cấu hình các lần thử lại, vì các lần thử lại có thể xảy ra ở nhiều cấp. Bảng sau đây trình bày việc bạn có thể làm để ứng phó với thất bại trong kiểm thử không ổn định:
Lỗi
Hành động
Trình mô phỏng không phản hồi trong một giây, kích hoạt thời gian chờ
Chạy lại quy trình kiểm thử không thành công
Không khởi động được trình mô phỏng
Chạy lại toàn bộ việc cần làm
Đã xảy ra lỗi kết nối trong giai đoạn thanh toán mã
Bắt đầu lại quy trình làm việc
Quan trọng là bạn phải ghi nhật ký và theo dõi xem phần nào trong hệ thống không ổn định và đầu tư vào việc đảm bảo CI hoạt động nhanh và đáng tin cậy, chỉ dựa vào số lần thử lại
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-27 UTC."],[],[],null,["# CI features\n\nThe following are some features that you can find in most CI systems.\n\nEnvironment\n-----------\n\nIt's important to choose and understand the hardware and software environment in\nwhich the system executes the workflow. Important considerations for Android\napplications are:\n\n- **Platform**: Linux, Mac, Windows, and their versions.\n- **Available memory**: Building apps and running emulators can use a lot of RAM and it's often necessary to tweak parameters such as the JVM's heap size to avoid out-of-memory errors.\n- **Preinstalled software**: CI systems usually provide images with a large collection of tools already available, such as the Java Development Kit (JDK), the Android Software Development Kit (SDK), build tools, platforms and emulators.\n- **Runner architecture and instruction set**: ARM, x86. This is important when using emulators.\n- **Environment variables** : Some are set by the CI system (for example: `ANDROID_HOME`) and you can set your own to, for example, avoid hardcoding credentials in your workflow.\n\nThere are many other aspects you should consider, such as the number of cores\navailable, and whether virtualization is enabled to run emulators.\n\nLogs and reports\n----------------\n\nWhen a step fails, the CI system notifies you and usually doesn't let you merge\nthe change. To find out what has gone wrong, look for errors in the logs.\n\nAdditionally, building and testing generates reports that are usually stored as\nartifacts of that particular build. Depending on the CI system, you can use\nplugins to visualize the results of those reports.\n\nCache and CI run times\n----------------------\n\nCI systems use a build cache to speed up the process. In its simplest form, they\nsave all the Gradle cache files after a successful build and restore them before\na new one. This relies on [Gradle's build cache](https://docs.gradle.org/current/userguide/build_cache.html) feature and should be\nenabled in your project.\n| **Note:** take into account the time that it takes for the cache to download as, if the cache becomes too big and it contains more than is necessary, it could be detrimental to the overall build time.\n\nSome ways to improve run times and reliability include:\n\n- **Modules**: Detecting which modules are affected by a change and only building and testing those.\n- **Skip caches**: If the build includes scripts that a developer has modified, ignore the build caches. It's safer to build from scratch.\n- **Shard tests**: Especially instrumented tests, it can be helpful to shard tests across multiple devices. This is supported by the Android runner, Gradle Managed Devices and Firebase Test Lab.\n- **Shard builds**: You can shard the build across multiple server instances.\n- **Remote cache** : You can also use [Gradle's remote cache](https://docs.gradle.org/current/userguide/build_cache.html).\n\nRetry failed tests\n------------------\n\nFlakiness refers to tests or tools that fail intermittently. You should always\ntry to find and fix the problems that generate flaky builds and tests, but some\nof them are difficult to reproduce, especially when running instrumented tests.\nA common strategy is to retry test runs whenever they fail, up to a maximum\nnumber of retries.\n\nThere is no single way to configure retries, as they can occur at multiple\nlevels. The following table outlines the action you might take in response to a\nflaky test failure:\n\n| Failure | Action |\n|--------------------------------------------------------------|-----------------------|\n| Emulator was unresponsive for a second, triggering a timeout | Rerun the failed test |\n| Emulator failed to boot | Rerun the whole task |\n| There was a connection error during the code checkout phase | Restart the workflow |\n\nIt's important to log and keep track of which parts of the system are flaky and\ninvest in keeping CI reliable and fast, only relying on retries"]]
