foto dari Unsplash untuk "pipeline"
Pendekatan umum
Hai Saya memulai serangkaian posting pada jaringan pipa dalam pengembangan dan tidak hanya itu membantu memverifikasi kualitas aplikasi mobile yang sedang dikembangkan. Gagasan utamanya adalah menyoroti semua pendekatan untuk pengembangan seluler yang relevan sekarang: pengembangan asli untuk Android dan iOS, React Native, Xamarin dan Flutter. Saya akan mulai dengan Android, tetapi pertama-tama saya ingin memberikan gambaran umum tentang apa ini semua.
Ingatlah bahwa ini adalah ikhtisar umum alat dan praktik yang dapat berguna selama pengembangan aplikasi Android, dan bukan tutorial tentang cara mengonfigurasi alat ini.
Untuk apa semua ini?
Mari kita mulai dengan kebenaran yang terkenal: semakin Anda menemukan cacat dalam aplikasi, semakin mahal untuk memperbaikinya. Misalkan Anda telah menemukan bug yang sudah dalam produksi. Penguji Anda harus mereproduksi bug ini secara lokal, mendaftarkannya, memprioritaskannya, meneruskannya ke pengembang, dan mereka, pada gilirannya, perlu memperbaikinya, membuat perakitan baru, mentransfernya kembali ke penguji sehingga mereka yakin bahwa semuanya sudah diperbaiki, dan kemudian membuat rilis rilis, dan hanya kemudian mengirim versi baru ke pengguna.
Banyak jam kerja bisa dihemat jika Anda memiliki mekanisme untuk mencegah munculnya bug di awal. Saya tidak mengatakan bahwa ada peluru perak yang menghilangkan semua bug - ini tidak mungkin. Tetapi yang mungkin adalah untuk membangun penghalang (juga dikenal sebagai gerbang kualitas) yang meningkatkan kemungkinan menangkap bug dalam kode Anda sedini mungkin.
Di komputer pengembang
Sebagai pengembang, Anda selalu mengerjakan mesin Anda dengan alat IDE dan baris perintah. Mari kita lihat apa yang ada untuk pengembang Android.
Android Studio
Ini sekarang merupakan opsi default untuk pengembang Android, dan karena didasarkan pada platform IntelliJ, ada banyak inspeksi untuk Java, Kotlin, dan XML. Saya menyarankan Anda untuk menyetujui dalam tim tentang aturan khusus yang ingin Anda gunakan, mengonfigurasikannya di satu komputer dan mengunggah file pengaturan.jar dengan aturan ini ke sistem kontrol versi Anda atau semacam alat kerja kolaboratif (seperti Confluence).
Pengaturan Inspeksi di Android Studio
AS juga memiliki perbaikan cepat yang dapat diterapkan pada kode Anda dengan menekan Alt + Enter.
Contoh perbaikan cepat dari Android Studio
Android Lint
Ini adalah alat analisis statis khusus untuk pengembangan Android, di luar kotak dengan ratusan aturan, yang dapat Anda gunakan. Lint juga dapat diluncurkan dari tugas Gradle (tugas), dan memberikan prompt langsung di Android Studio, dan menghasilkan laporan. Ini memiliki banyak pemeriksaan, dibagi ke dalam kategori - keamanan, internasionalisasi, kegunaan, kinerja ...
Tetapi kemampuan untuk menambahkan aturan Anda sendiri membuatnya sangat kuat. Sebagai contoh, Kamar memiliki seperangkat aturan sendiri, perpustakaan penebangan kayu memiliki sendiri. Anda dapat membuat aturan untuk tim atau proyek Anda dan pastikan bahwa tidak ada yang membuat kesalahan tipikal tertentu. (Ngomong-ngomong, segera di konferensi Mobius akan ada laporan tentang ini, menjelaskan sisi teoretis dan praktis).
Contoh Laporan Android Lint
Analisis lebih statis
Tentu saja, ada banyak alat analisis statis yang dirancang tidak khusus untuk Android, tetapi secara umum untuk Java dan Kotlin : PMD , FindBugs (ditinggalkan, gunakan SpotBugs ), Checkstyle , Ktlink , Detekt , dan lainnya. Pilih sesuai keinginan Anda, mengintegrasikannya ke dalam pipa Anda dan memastikan penggunaannya yang sebenarnya (bagaimana tepatnya? Baca terus).
Laporkan contoh dari FindBugs
Tetapi itu tidak cukup untuk memiliki alat yang menyediakan data tentang apa yang perlu diperbaiki. Anda juga akan menemukan informasi berikut berguna:
- Bagaimana cakupan kode dengan tes berubah dari waktu ke waktu?
- Berapa lama saya bisa memperbaiki semua masalah yang ditemukan?
- Berapa banyak kode duplikat yang ada dalam proyek ini?
- Bagaimana cara memperluas aturan saya ke beberapa tim?
Dan masih banyak lainnya. Di EPAM Systems kami fokus pada kualitas, jadi kami telah memilih SonarQube sebagai alat untuk menjawab pertanyaan-pertanyaan ini. Untuk manfaat SonarQube lainnya, klik di sini .
Pengujian unit
Mudah-mudahan Anda tidak perlu meyakinkan Anda lagi bahwa kode sialan Anda memerlukan pengujian unit karena berbagai alasan . Tidak masalah jika Anda mengikuti TDD, mematuhi prinsip piramida pengujian atau ide baru jamur pengujian . Tidak begitu penting tingkat cakupan yang Anda tetapkan sebagai tujuan Anda, dalam hal apa pun, pengujian unit Anda merupakan komponen yang diperlukan. Jadi, Anda perlu menulis dan menjalankannya! Untungnya, lebih dari 11 tahun evolusi, kami mendapat mekanisme yang cukup nyaman untuk menjalankan tes dari plug-in Gradle dan Android Gradle.
Dalam proyek Android, proyek default memiliki tugas testDebugUnitTest (untuk Anda, tentu saja, mungkin berbeda tergantung pada rasa), dan dialah yang menjalankan tes. Pastikan untuk menggunakannya dan cakupan kode meningkat dari waktu ke waktu. Keuntungan dari tes unit Java adalah mereka bekerja pada workstation JVM, dan bukan pada Dalvik / ART, yang memberikan keuntungan dalam kecepatan.
Dalam kasus pengujian unit android, ada satu masalah mendasar: ketergantungan pada Android SDK. Ini adalah salah satu alasan mengapa semua pendekatan ini ke lapisan UI muncul seperti MVP, MVVM, MVI dan MV * lainnya. Masalah spesifik tergantung pada kelas pada Android adalah bahwa unit test jatuh karena penggunaan bertopik Android itu sendiri, yang hanya membuang pengecualian. Tentu saja, ada beberapa opsi: melewati tes untuk kelas ini, atau mengekstrak beberapa logika ke kelas lain, atau membuat antarmuka untuk kelas yang bergantung pada Android untuk menguji beberapa logika tingkat tinggi, atau menggunakan Robolectric (yang jauh dari ideal). Pilihan lain adalah dengan menggunakan tes instrumen, yang mungkin cocok untuk memeriksa perilaku suatu Kegiatan, tetapi tren saat ini adalah bahwa Aktivitas tidak boleh mengandung tes.
Untuk pertanyaan tentang pertanggungan: Anda ingin tahu apa itu pada saat Anda dan bagaimana itu berubah dari waktu ke waktu, sehingga Anda akan memerlukan alat untuk ini juga. Sejauh yang saya tahu, jacoco adalah standar industri untuk Jawa, dan memiliki dukungan Kotlin.
Tes Instrumentasi
Tes ini dijalankan pada emulator Android, yang memungkinkan mereka untuk menggunakan Kerangka Android. Sayangnya, mereka lambat dan tidak stabil (karena beberapa masalah dengan emulator), jadi sebagian besar pengembang yang saya kenal secara pribadi mencoba menghindarinya. Tetapi dukungan mereka ada di Gradle dan Android Studio, jadi bagi Anda, mereka mungkin cocok.
Audit keamanan
Selain kesalahan sederhana, kesalahan ketik, masalah dengan copy-paste dan sejenisnya, ada juga kategori besar masalah yang harus Anda perhatikan: keamanan. Tentu saja, Android Lint sudah memberikan beberapa tips yang relevan, tetapi lebih baik untuk merawat alat khusus untuk tugas ini. Alat-alat ini dapat bekerja dalam mode statis dan dinamis; tergantung pada persyaratan keamanan Anda, Anda mungkin ingin menggunakan salah satu dari mode ini, atau keduanya. Anda mungkin ingin memulai, misalnya, dengan Kerangka Keamanan Seluler , dan kemudian mempertimbangkan opsi berbayar.
Untungnya, ada daftar alat analisis statis yang dikompilasi langsung oleh OWASP. Misalnya, Anda dapat memilih Temukan Keamanan Bug atau menggunakan OWASP SonarCube Project .
Verifikasi Verifikasi
Seperti yang saya katakan, semakin pendek siklus umpan balik, semakin sedikit waktu dan uang yang Anda habiskan untuk memperbaiki bug. Jadi saya ingin memastikan bahwa kode tersebut sesuai dengan kualitas produksi sebelum bahkan sampai ke repositori atau bahkan dikomunikasikan secara lokal. Tentu saja, Anda cukup meminta pengembang Anda untuk melakukan pemeriksaan, tetapi ada opsi yang jauh lebih baik: Git hooks.
Saya sarankan menambahkan kait pra-komit untuk semua pemeriksaan yang kita bahas di atas: Lint, analisis kode statis, dan tes unit. Contoh dari proses pengaturan dapat ditemukan di sini .
Saluran Pipa CI / CD
Sangat sulit untuk membayangkan proyek Android tanpa pipa CI / CD. Tujuan Anda adalah mengulangi semua pemeriksaan di atas pada tahap perakitan. Ada beberapa alasan untuk ini:
- Git hook dapat dengan mudah dielakkan dengan opsi --no-verifikasi
- Kode berhasil dapat melewati semua pemeriksaan secara lokal, tetapi memperkenalkan masalah setelah penggabungan
- Perlu laporan pengujian dan liputan
Laporkan contoh di bitrise.io
Untungnya, Anda hanya perlu menyebutkan pemeriksaan keamanan ini secara langsung di skrip build Gradle, atau menjalankan tugas yang sesuai dalam pipa CI / CD Anda. Jika Anda mengalami kesulitan membangun saluran pipa, saya baru-baru ini membuat presentasi di konferensi DevOops di DevOps seluler pada tahun 2019.
Silakan lakukan hal berikut:
- Jalankan semua cek untuk permintaan tarik. Jangan biarkan menggabungkan permintaan apa pun yang melanggar aturan apa pun. Ini sangat penting: jika aturan itu tidak dijalankan, maka, pada kenyataannya, itu tidak ada.
- Jalankan semua pemeriksaan selama perakitan dan penyebaran. Anda tidak ingin menurunkan bilah kualitas Anda.
- Jika build rusak, ini adalah prioritas pertama. Tim harus segera memperbaiki masalah, karena itu melanggar praktik pengiriman berkelanjutan Anda dan mencegah tim dari menulis kode kualitas.
Dan semoga berhasil meningkatkan kode Anda!
Jika Anda menyukai artikel ini, ikuti saya di Twitter sehingga Anda tidak melewatkan yang berikut ini. Dan jika Anda akan berada di Moskow pada bulan Desember atau Anda dapat datang, datanglah ke konferensi Mobius kami dan cari tahu banyak hal lain tentang pengembangan untuk Android (dan iOS)!
PS Terima kasih kepada vixentael untuk mendekati masalah keamanan, ke Alexei Nikitin untuk ulasan dan komentar, kepada Alexander Bakanov untuk proofreading.