Implementasi CI/CD pada Android App Development di Kitabisa
Tim Mobile Engineer di Kitabisa terbentuk pada Maret 2019, jadi tim kami terbilang masih cukup baru. Diawali oleh seorang freelancer dengan codebase yang sangat baik sehingga sangat memudahkan kami ketika melanjutkannya. Dan sekarang tim kami terdiri dari 2 Android Engineer, 2 iOS Engineer dan 1 Lead Engineer, dengan 2 product yang sedang kami kembangkan.
Dengan keterbatasan jumlah tim yang kami miliki, kami tetap ingin men-deliver fitur yang kami kembangkan dengan cepat dan tentu saja dengan kualitas yang terjaga. Itulah kenapa kami menginvestasikan waktu kami pada CI/CD (Continuous Integration & Continuous Delivery/Deployment).
Sebelum Mengimplementasikan CI/CD
Yap! Cukup panjang dan memakan waktu, terutama pada langkah build APK yang tidak hanya memakan waktu tapi juga memakan resource device kita. Belum lagi jika code yang kita buat tidak lolos code review atau fitur yang kita buat tidak lolos test, kita harus build APK berulang-ulang bukan? Dari sini kita bisa melihat ada beberapa langkah yang bisa dilakukan oleh mesin secara otomatis, yaitu:
- Build APK dengan Staging Environment
- Publish ke Beta (Fabric)
- Build APK dengan Production Environment
- Publish ke Playstore
Setelah Mengimplementasikan CI/CD
Trigger yang kami gunakan untuk menjalankan CI/CD adalah ketika developer membuat pull request, kemudian pull request tidak akan di-merge sampai mendapat approval dari QA dan developer lain, dengan begitu akan meminimalisir code bug yang masuk. Lalu bagaimana jika QA menemukan bug pada fitur yang kita buat? Atau code yang kita tulis tidak lolos code review? Kita hanya perlu push commit kita ke branch yang masih dalam kondisi open pull request, maka CI/CDnya akan jalan kembali, dan begitu seterusnya sampai QA dan developer lain memutuskan untuk approve pull request kita.
Bagaimana Kami Melakukannya?
Sebelum mulai, kami berasumsi bahwa kalian sudah memahami atau memiliki hal-hal berikut:
- Sudah setup project di CircleCI
- Familiar dengan gradle
- Memiliki keystore beserta kredensialnya
- Sudah mem-publish aplikasi kalian di Beta (Fabric)
- Sudah mem-publish aplikasi kalian di Playstore
Auto Bump Version dan Set Release Note
Untuk auto bump version kita akan menggunakan environment variable dari CircleCI, yaitu CIRCLE_BUILD_NUM. Build number ini akan terus bertambah setiap CircleCI job berjalan. Dan untuk release note, kita akan mengambilnya dari git commit message. Tetapi auto set release note ini hanya untuk APK yang dipublish ke Beta (Fabric), untuk ke playstore kami masih menggunakan cara manual.
Selanjutnya kita panggil fungsi ini di app/build.gradle
Signing APK
Kami memiliki 2 build type, yaitu debug dan release. Untuk build type debug kami tempatkan langsung debug.keystore di repository. Sedangkan untuk type release sedikit berbeda, demi keamanan kami men-generate file keystore sebagai base64, kemudian menyimpannya sebagai environtment variable di CircleCI (kita akan melakukannya di step terakhir).
Publish APK Menggunakan Gradle Play Publisher
Pada langkah ini kita akan mengikuti instruksi dari repository Gradle Play Publisher. Jadi kita perlu membuat Google Service Account terlebih dahulu, kalian bisa membuatnya di Play Console API Access, setelah selesai jangan lupa untuk mengunduh private key-nya. Kemudian kita akan melakukan hal yang sama seperti file keystore, yaitu men-generate base64 dari file tersebut. Selanjutnya untuk konfigurasi Gradle Play Publisher cukup sederhana.
Config CircleCI
Pertama generate base64 dari file keystore dan private key.
$ cat path/to/yourprivatekey.keystore | base64Lakukan hal yang sama untuk private key Google Service Account, kalian akan mendapat output berupa base64. Copy outputnya kemudian save sebagai environment variable di CircleCI. Untuk kredensial keystore kalian bisa langsung set sebagai environment variable.
Kemudian setup trigger hanya untuk open pull request.
Selanjutnya kita akan konfigurasi CircleCI sesuai dengan automation flow yang sudah kita bahas sebelumnya. Karena konfigurasinya cukup panjang di sini kami hanya akan menampilkan konfigurasi workflownya saja, untuk lengkapnya kalian bisa klik di sini.
That’s it! Commit dan push code kalian, kemudian buat pull request. And let the magic happen!
Kesimpulan
Proses build APK biasanya memakan waktu yang tidak sedikit, sekitar 1–5 menit tergantung dari seberapa besar projectnya dan spesifikasi device yang dimiliki. Dan saat proses itu berjalan sangat sulit bagi developer untuk tetap melanjutkan pekerjaannya karena resource device yang diambil oleh proses tersebut cukup besar. Maka dari itu mengimplementasikan CI/CD adalah pilihan yang sangat tepat, karena kita dapat memindahkan proses build APK yang cukup berat itu ke device lain serta dapat menjalankannya secara otomatis, sehingga akan mempercepat proses development.
Hal yang Ingin Kami Implementasikan Selanjutnya
Selanjutnya kami ingin mengimplementasikan static code analysis menggunakan SonarQube, untuk mengetahui potensi bug, security issues, maintainability code, code coverage dan duplikasi yang terjadi di code kita. Dengan begitu developer akan semakin sadar dengan kondisi codenya secara keseluruhan dan diharapkan akan berdampak pada meningkatnya kualitas code yang ditulis.
Kami yakin masih banyak hal yang harus kami improve, tidak tertutup hanya untuk hal yang berkaitan dengan CI/CD tapi juga teknologi secara luas dan tentu saja dengan tujuan semakin banyak menghubungkan #OrangBaik.
