Gitlab CI/CD dan Build Flutter Project

Dalam mengembangkan perangkat lunak yang memiliki fase yang sangat cepat, hampir tiap hari para developernya membuat kode baru yang bahkan hampir tiap hari pula produk perangkat lunak tersebut diperbarui. Dan tentunya kode yang akan masuk untuk di rilis ke konsumen/pengguna diinginkan sudah di test terlebih dahulu untuk memenuhi kualitas baik yang diinginkan, selain itu juga jika produk perangkat lunak tersebut adalah pekerjaan dalam sebuah tim, tentunya ingin untuk mudah di integrasikan code nya antar sesama developer. Kedua hal tersebut dilakukan secara repetitif. Untungnya, kedua hal tersebut dapat dilakukan automatisasi dengan mempraktekkan yang namanya CI/CD, sehingga dalam implementasinya, kedua hal tersebut dapat dilakukan dengan cepat dan mengurangi beban developer.

Apa itu CI/CD

Secara singkat, CI/CD dapat dikatakan sebagai sebuah rangkaian pekerjaan dari kode yang sudah dibangun kemudian menghasilkan produk yang siap untuk digunakan konsumen/pengguna, kemudian rangkaian pekerjaan tersebut dapat dilakukan dengan cepat, terautomatisasi, dan dapt dilakukan secara repetitif (berkali-kali). Proses pengintegrasian kode baru yang masuk ke dalam repositori, biasanya di integrasikan dengan pengujian tes yang sesuai atau biasanya syntaxing check menggunakan linter disebut sebagai CI (Continuous Integration), kemudian setelah berhasil di integrasikan pada langkah CI, kode tersebut disampaikan ke lingkungan produksi yang akan secara automatis siap untuk dipakai oleh konsumen/pengguna dan langkah tersebut dinamakan CD (continuous delivery)

Dapat dilihat, kata continuous bukan berarti proses tersebut selalu berjalan, melainkan mengartikan bahwa hal tersebut dilakukan secara berkala, terautomatisasi, dan dengan cepat.

Tools untuk CI/CD dan mengapa Gitlab CI/CD

Ada banyak tools yang dapat membantu dalam melakukan CI/CD. Beberapa yang telah dikenal dan digunakan di banyak repository adalah Jenkins, Azure Pipelines, Travis CI, GitLab CI, dan masih banyak juga yang lain. Dan untuk proyek perangkat lunak saya, kelompok saya menggunakan Gitlab CI untuk tools CI/CD nya.

Alasan utama kelompok saya menggunakan Gitlab CI adalah karena pada proyek perangkat lunak ini, kelompok saya diwajibkan untuk menggunakan GitLab sebagai remote repository nya, sehingga Gitlab CI mempunyai lebih banyak kemudahan dalam setup nya karena sudah terintegrasikan dengan GitLab. GitLab CI telah automatis akan menjalankan CI/CD pipelinenya tiapkali ada merge request, dan lagi menurut saya GitLab CI relatif lebih mudah untuk dipelajari karena banyak contoh di internet yang apabila repository nya adalah GitLab, telah kebanyakan menggunakan GitLab CI. Selain itu juga, terdapat panduan awal dan dokumentasi lengkap pada halaman Quick Start yang disediakan oleh Gitlab CI. Satu satunya hal yang perlu anda lakukan hanyalah membuat berkas .gitlab-ci.yml pada root’s directory dan memastikan project gitlabmu telah terhubung dengan runner dan dengan begitu, kamu sudah berhasil setup Gitlab CI di project gitlabmu.

Note : Dalam proyek perangkat lunak ini, asisten dosen kelompok saya telah memberikan shared runner kepada semua project yang berkaitan tentang proyek perangkat lunak pada semester itu. Jika kamu ingin mengkonfigurasi sendiri runnermu, dapat dilakukan pada menu Settings ➔ CI/CD

Membuat script CI/CD mu

Saatnya membuat script untuk CI/CD mu. Saya hanya akan menjelaskan secara singkat bagaimana script di dalam berkas .gitlab-ci.yml dapat bekerja.

Dalam Gitlab CI akan terdiri dari beberapa stages dan di dalam tiap stages nya akan terdiri dari beberapa jobs. Dan jobs inilah yang merupakan bagian utama dari .gitlab-ci.yml . Jobs akan dijalankan oleh runner yang kemudian akan dijalankan dengan environment pada runner.

Pipeline pada Gitlab CI biasanya terdiri dari 3 stages berikut :

• build — biasanya berisi script untuk membuat perangkat lunak kita berjalan
• test — biasanya berisi script untuk melakukan test terhadap code kita, seringkali stages ini dimanfaatkan untuk mendapatkan code coverage yang kemudian ditampilkan persentase coveragenya di repository kita
• deploy — biasanya berisi script untuk merilis kode kita ke lingkungan production

Tentunya, kamu tidak perlu memiliki stages yang sama persis seperti diatas. Gunakan sesuai kebutuhan, dan jika perlu untuk menambah stages juga kamu dapat menambahkannya

Implementasi Gitlab CI di proyek saya

Untuk proyek perangkat lunak saya, saya memiliki 2 repositori yang terpisah. Satu repositori untuk mobile application, dan yang satunya lagi adalah backend. Dan pada artikel ini, saya akan membagikan bagaimana kelompok saya setup untuk mobile application.

Pada mobile application, kelompok saya menggunakan Flutter untuk dapat membuat file .apk untuk perangkat android. Dan dalam artikel ini, saya akan membagikan bagaimana kelompok saya mengimplementasikan Gitlab CI pada repositori mobile application ini.

Berikut berkas snippet untuk .gitlab-ci.yml :

Berikut adalah beberapa penjelasan mengenai berkas Gitlab CI tersebut :

• Kelompok saya memiliki 4 stages dalam pipeline Gitlab CI, yaitu : lint untuk membuat clean code yang sesuai dengan linter, test untuk melakukan testing kepada kode yang ada pada repositori tersebut, sonar untuk melakukan integrasi ke SonarQube, dan build untuk melakukan build pada kode yang telah ada di repositori hingga nantinya akan membuat file .apk pada artifact
• Job pertama yang ada pada Gitlab CI kami adalah flutter_analyze yang merupakan bagian dari stage lint . script adalah satu satunya keyword pada bagian job yang harus ada (required). Dan pada job ini, dilakukan pengecekan clean code yang sesuai dengan standar flutter dengan melakukan flutter_analyze. Dan pada linter ini pula kami membolehkan jika ada kode yang fail pada tahap ini, tetap dilanjutkan pipelinenya karena linter menurut kelompok kami sebisa mungkin tidak menghalangi deployment yang urgent jika dibutuhkan
• Job kedua yang ada pada Gitlab CI kami adalah unit_test. Job ini merupakan bagian dari stage test.Dalam job ini, kelompok saya menulis script yang melakukan perintah untuk menjalankan unit test yang telah di buat kemudian menampilkan code coverage. artifacts digunakan untuk memberikan list berkas atau folder yang akan dilampirkan pada job. Sebagai contoh, pada job ini, kami memberikan file coverage yang sebelumnya telah di generate dari test
• Job ketiga dan keempat adalah SonarScannerDev dan SonarScanner. Dalam job ini dilakukan pengintegrasian code smells ke SonarQube, dan secara spesifik dalam job ini terdapat keyworddependencies, yang mana mengindikasikan bahwa pada job ini membutuhkan artifact dari job unit_test.
• Dan job terakhir adalah flutter_build_android. Pada job ini dilakukan build berkas .apk berdasar kode yang telah ada di repositori, dan berkas .apk tersebut dapat diakses di artifacts job ini. Pada nantinya, berkas .apk ini dapat di validasi untuk kemudian dapat di rilis ke Google Play Store.

References

1. https://docs.gitlab.com/ee/ci/
2. https://opensource.com/article/18/8/what-cicd