Berikut adalah beberapa fitur yang dapat Anda temukan di sebagian besar sistem CI.
Lingkungan
Penting untuk memilih dan memahami lingkungan hardware dan software tempat sistem menjalankan alur kerja. Pertimbangan penting untuk aplikasi Android adalah:
- Platform: Linux, Mac, Windows, dan versinya.
- Memori yang tersedia: Mem-build aplikasi dan menjalankan emulator dapat menggunakan banyak RAM, dan sering kali parameter seperti ukuran heap JVM perlu disesuaikan untuk menghindari error kehabisan memori.
- Software bawaan: Sistem CI biasanya menyediakan image dengan sejumlah besar alat yang sudah tersedia, seperti Java Development Kit (JDK), Android Software Development Kit (SDK), alat build, platform, dan emulator.
- Arsitektur runner dan kumpulan petunjuk: ARM, x86. Hal ini penting saat menggunakan emulator.
- Variabel lingkungan: Beberapa variabel ditetapkan oleh sistem CI (misalnya:
ANDROID_HOME) dan Anda dapat menetapkannya sendiri untuk, misalnya, menghindari kredensial hardcode di alur kerja Anda.
Ada banyak aspek lain yang harus Anda pertimbangkan, seperti jumlah core yang tersedia dan apakah virtualisasi diaktifkan untuk menjalankan emulator.
Log dan laporan
Jika ada langkah yang gagal, sistem CI akan memberi tahu Anda dan biasanya tidak mengizinkan Anda menggabungkan perubahan. Untuk mengetahui apa yang salah, cari kesalahan di log.
Selain itu, pembuatan dan pengujian akan menghasilkan laporan yang biasanya disimpan sebagai artefak dari build tertentu tersebut. Bergantung pada sistem CI, Anda dapat menggunakan plugin untuk memvisualisasikan hasil laporan tersebut.
Waktu proses cache dan CI
Sistem CI menggunakan cache build untuk mempercepat prosesnya. Dalam bentuknya yang paling sederhana, mereka menyimpan semua file cache Gradle setelah build berhasil dan memulihkannya sebelum yang baru. Hal ini bergantung pada fitur cache build Gradle dan harus diaktifkan di project Anda.
Beberapa cara untuk meningkatkan waktu proses dan keandalan meliputi:
- Modul: Mendeteksi modul mana yang terpengaruh oleh perubahan dan hanya mem-build dan mengujinya.
- Lewati cache: Jika build menyertakan skrip yang telah diubah developer, abaikan cache build. Lebih aman untuk membangun dari awal.
- Pengujian shard: Pengujian sharding khusus berinstrumen, dan dapat berguna untuk melakukan sharding pengujian di beberapa perangkat. Dukungan ini didukung oleh runner Android, Perangkat yang Dikelola Gradle, dan Firebase Test Lab.
- Build shard: Anda dapat melakukan sharding build di beberapa instance server.
- Cache jarak jauh: Anda juga dapat menggunakan cache jarak jauh Gradle.
Coba lagi pengujian yang gagal
Kelemahan mengacu pada pengujian atau alat yang gagal sesekali. Anda harus selalu mencoba menemukan dan memperbaiki masalah yang menghasilkan build dan pengujian yang tidak stabil, tetapi beberapa di antaranya sulit direproduksi, terutama saat menjalankan pengujian berinstrumen. Strategi yang biasa digunakan adalah mencoba kembali pengujian setiap kali gagal, hingga jumlah maksimum percobaan ulang gagal.
Tidak ada satu cara untuk mengonfigurasi percobaan ulang karena hal ini dapat terjadi di beberapa level. Tabel berikut menguraikan tindakan yang dapat Anda lakukan sebagai respons terhadap kegagalan uji yang tidak stabil:
Gagal |
Tindakan |
|---|---|
Emulator tidak responsif selama satu detik, sehingga memicu waktu tunggu |
Menjalankan kembali pengujian yang gagal |
Emulator gagal di-booting |
Jalankan kembali seluruh tugas |
Ada error koneksi selama fase checkout kode |
Mulai ulang alur kerja |
Penting untuk mencatat dan melacak bagian sistem yang tidak stabil dan berinvestasi dalam menjaga CI yang andal dan cepat, dengan hanya mengandalkan percobaan ulang