Get best of the week

Sumber terbuka: CI / CD dan infrastruktur pengujian Avito untuk Android

Kami memindahkan Avito untuk infrastruktur sumber terbuka Android: Plugin Gradle, emulator, dan perpustakaan uji. Kode kami akan berguna dalam mengotomatisasi CI / CD, dan juga akan memfasilitasi penulisan dan dukungan autotest.

Dalam artikel ulasan ini, kami akan menjelaskan mengapa kami memutuskan untuk membuat pekerjaan kami terbuka, tentang perpustakaan proyek yang paling signifikan dan akan mengarahkan ke mana harus pergi dengan masalah yang muncul. Kami akan menganalisis secara terperinci masing-masing perpustakaan, plugin Gradle, dan pendekatan pengembangan kami dalam materi berikut.



Siapakah kita dan apa yang kita lakukan


Kami sedang mengerjakan industri Android di tim platform Speed. Ada empat dari kita:
Seryozha Boishtyan
Senior insinyur
akun Twitter


Dima Voronin
Memimpin akun Twitter insinyur



Zhenya Krivobokov
Senior insinyur
akun Twitter


Daniil Popov
Senior insinyur
akun Twitter


Kami bertanggung jawab untuk mengirimkan perubahan di semua aplikasi Android Avito kepada pengguna dengan lebih cepat. Area tanggung jawab kami meliputi:

  • Pekerjaan lokal dengan proyek: sehingga semuanya cepat dirakit dan IDE tidak melambat.
  • Pipa CI: tes, semua kemungkinan pemeriksaan.
  • CD: alat untuk insinyur rilis.

Mengapa kita membutuhkan open source


Kami ingin tidak hanya mencerminkan kode dalam repositori terbuka di Github, tetapi untuk melakukannya demi kepentingan diri sendiri dan komunitas teknik. Alasan utama untuk membawa proyek ke open source adalah lima:

  • Dapatkan umpan balik.
  • Mempengaruhi standar industri.
  • Pelajari hal-hal baru.
  • Mempengaruhi perpustakaan pihak ketiga.
  • Tingkatkan merek pribadi Anda.

Mari kita bahas secara singkat.

Dapatkan umpan balik dan buat kode lebih mudah untuk digunakan kembali


Kami membuat penyetelan untuk teknisi Avito, dan pengguna kami membutuhkan semua solusi untuk hanya bekerja. Kami tidak memiliki pandangan dari pengembang yang memecahkan masalah serupa. Akan keren jika mereka menunjukkan masalah dalam implementasi internal dan kenyamanan menghubungkan ke proyek kami.

Kita telah melihat bagaimana kode porting ke Github menyoroti masalah penggunaan kembali. Ketika Anda memahami bahwa perusahaan lain dapat menggunakan ini, Anda melihat arsitektur secara berbeda. Menggunakan kembali kode bukanlah tujuan itu sendiri. Tetapi kriteria eksternal ini mengatakan banyak tentang kualitas arsitektur dan fleksibilitasnya.

Mempengaruhi standar industri


Kami telah mengembangkan infrastruktur untuk aplikasi seluler sejak 2017 dan secara teratur membicarakannya di konferensi dan rapat:


Selain cerita, kami selalu ingin berbagi kode dan memberikan kesempatan untuk menggunakannya kembali. Memang, banyak pengembang Android menghadapi tantangan serupa:

  • Cara menulis autotest sehingga bermanfaat.
  • Cara menjalankannya dalam permintaan tarik.
  • Cara lebih murah untuk memelihara infrastruktur.

Tidak ada solusi yang diterima secara umum dan mapan untuk tugas-tugas ini - setiap perusahaan beroperasi dengan caranya sendiri. Kami berbagi praktik terbaik kami sehingga dalam proyek-proyek baru pengembang tidak perlu mengumpulkan informasi sedikit demi sedikit tentang pengujian aplikasi seluler dan membangun CI / CD. Saya ingin memiliki solusi siap pakai untuk masalah rutin alih-alih menulis sepeda saya. Dan, bahkan jika tidak ada yang menggunakan kode proyek dalam bentuk aslinya, pengembang akan dapat memata-matai pendekatan kami dan meningkatkan perpustakaan mereka sendiri.

Belajar dengan menjelaskan kepada orang lain


Menempatkan kode di open source saja tidak cukup. Praktik, pendekatan, cara menemukan masalah dan membuat keputusan penting. Menunjukkan kepada mereka, kami memeriksa bagaimana ide-ide kami dan proposal siap pakai bekerja di luar Avito.

Mempengaruhi perpustakaan pihak ketiga dan memperbaiki masalah mereka lebih cepat


Bayangkan Anda sedang menghadapi masalah di Android atau perpustakaan dan tidak dapat menemukan solusinya. Anda memerlukan bantuan dari komunitas atau pembuat kode. Anda mengajukan pertanyaan tentang Stack Overflow, membuat bug di Google IssueTracker, menjelaskan semuanya secara terperinci, tetapi masalahnya tidak mereproduksi. Anda diminta test case. Semua ini membutuhkan waktu ekstra.

Sumber terbuka membantu Anda membuat contoh yang dapat direproduksi lebih cepat. Kami memiliki aplikasi uji yang menggunakan bagian dari infrastruktur. Tugas utamanya adalah dogfooding, yaitu, sedini mungkin untuk memverifikasi dengan contoh sederhana dan terisolasi bahwa semuanya berfungsi. Tetapi aplikasi yang sama ini membuatnya lebih mudah untuk menunjukkan bug. Ketika kita memberikan contoh yang dapat direproduksi di perpustakaan asing, penulisnya lebih mudah untuk memahami apa masalahnya. Ini meningkatkan kemungkinan bahwa dia akan melakukan perbaikan.

Popularitas proyek open source juga meningkatkan kemungkinan mereka akan memperhatikan Anda. Menunjukkan masalah di perpustakaan dengan sekelompok bintang dan pengguna meningkatkan tekanan, lebih sulit untuk diabaikan. Mendapatkan hasil seperti itu tanpa sumber terbuka lebih sulit - aplikasi Anda harus sangat populer atau Anda harus mengetahuinya secara pribadi.

PR dan motivasi pribadi


Terakhir, namun tidak kalah pentingnya, adalah keuntungan pribadi. Semua orang mendapat manfaat dari publisitas pekerjaan sehari-hari. Perusahaan menarik perhatian karena produk yang bermanfaat, dan kami memompa merek pribadi sebagai insinyur dan mendapatkan motivasi tambahan untuk bekerja. Anda tidak perlu lagi mencari waktu di malam hari untuk proyek Anda sendiri atau melakukan di perpustakaan sumber terbuka pihak ketiga.

Apa yang dibawa ke open source


Kami memasukkan hampir semua infrastruktur pengujian Android dan CI / CD kami ke repositori Github . Untuk memudahkan pengembang lain dalam menavigasi proyek, semua modul dikelompokkan berdasarkan tujuan:




Saya akan mencatat beberapa perpustakaan yang paling signifikan.

Pelari ujian


Ini adalah plugin gradle untuk menjalankan tes instrumentasi. Analog terdekat adalah Marathon , tetapi analog kami hanya ditulis untuk Android.

Pelari ujian:

  • Menjelaskan tes mana yang harus dijalankan. Ada pemfilteran menurut anotasi, menurut paket, dari hasil peluncuran terakhir.
  • Menjelaskan emulator mana yang akan menjalankan tes. Membackupnya ke Kubernetes atau terhubung ke emulator lokal.
  • Tetapkan kondisi untuk memulai kembali tes.
  • Mengirim laporan akhir dengan hasil uji coba.

Hasil disimpan dalam TMS khusus (sistem manajemen pengujian), tidak dalam sumber terbuka. Kami sedang mengerjakan kemungkinan menghubungkan implementasi lain.



Analisis dampak


Kami memiliki sekitar 1.600 tes instrumentasi dan 10 unit unit. Kami ingin menjalankan semua tes untuk setiap perubahan kode, tetapi ini tidak mungkin - prosesnya akan memakan waktu terlalu lama.

Solusi sederhana adalah dengan membagi tes secara manual menjadi set yang berbeda, misalnya, tes asap, cepat, lambat, dan hanya menjalankan sebagian. Tetapi dengan pendekatan ini, selalu ada peluang untuk melewatkan kesalahan, karena tidak jelas set tes mana yang optimal. Solusi ideal adalah memahami set tes minimum yang akan memverifikasi semua perubahan. Ini disebut analisis dampak uji .

Kami menulis plugin Gradle yang mencari perubahan dalam modul, mem-parsing tes dan menentukan mana yang akan dijalankan.



Modul dan pendekatan utama dijelaskan secara lebih rinci dalam dokumentasi proyek .
Sekarang dia tidak terlalu baik, dan bahkan tidak semua diterjemahkan. Kami ingin membuat dokumentasi lebih mudah dipahami, dan kami membutuhkan bantuan Anda. Beri tahu kami apa yang harus diselesaikan dan dikoreksi dalam teks di obrolan telegram kami .



Bagaimana perpustakaan kami dapat bermanfaat


Karena proyek memiliki banyak komponen, penggunaannya tergantung pada kebutuhan Anda. Jika Anda memecahkan masalah yang sama atau hanya ingin memahami teknologinya - jangan ragu untuk menulis kepada kami dalam obrolan telegram dalam bahasa Rusia atau bahasa Inggris . Kami akan memberi tahu Anda apa yang kami ketahui, mencoba membantu dan menunjukkan contoh yang relevan.

Anda bisa bertanya apa saja:

  • Bagaimana Anda bekerja dengan tes yang tidak stabil?
  • Mengapa begitu banyak kode? Dia tidak berguna.
  • Mengapa semua kode dalam plugin Gradle, bukan skrip Python?

Jika Anda ingin menggunakan modul tertentu, Anda dapat mencobanya di aplikasi uji . Sekarang ini menunjukkan contoh menggunakan test runner.

Sayangnya, kami masih memiliki beberapa contoh penggunaan kembali di proyek lain, jadi integrasi masih dapat mengungkapkan pembatasan yang tidak diketahui. Menulis kepada kami jika ini terjadi, dan kami akan melihat apa yang perlu diselesaikan.

Kesimpulan


Dalam artikel berikut kami berencana untuk membicarakan:

  • Pelari ujian kami.
  • Anatomi tes - apa yang terjadi dengan menekan tombol "Jalankan" di IDE untuk mendapatkan hasilnya.
  • Bagaimana kami berjuang dengan ketidakstabilan tes dan infrastruktur.
  • Pendekatan kami dalam menulis infrastruktur.
  • Bagaimana kami mengurangi waktu rilis dari bulan ke minggu.

Ada ide tentang topik yang lebih umum:

  • Cara memulai tes menulis.
  • Dasar-dasar pengujian untuk pemula - tentang pendekatan umum dan teknologi.

Beri tahu kami di komentar apa yang akan Anda ketahui. Jadi kita akan mengerti teks mana yang harus ditulis terlebih dahulu.

More articles:


All Articles