Continuous Integration and Continuous Deployment
Dalam pengembangan perangkat lunak, terutama dalam agile methodology, kita dituntuk untuk menghasilkan perangkat lunak dengan kualitas sebaik mungkin dalam waktu yang singkat, CI/CD dapat membantu kita dalam meminimalisasi waktu yang kita gunakan dalam melakukan integrasi dan deployment aplikasi, sehingga kita dapat lebih berfokus dalam mengerjakan requirements aplikasi
Continuous Integration (CI)
CI merupakan bagian dari CI/CD, secara singkat dengan CI kita menginginkan semua bagian dari aplikasi yang kita buat menuju ke tempat yang sama, melewati proses yang sama, dan memiliki hasil yang mudah untuk di akses.
Contoh paling sederhana dari continuous integration adalah melakukan commit semua pekerjaan kita ke dalam sebuah repository. Dalam hal ini, kita mengintegrasikan semua kode dari aplikasi kita ke dalam tempaat yang sama, yaitu sebuah repository. Hal ini merupakan awal dari proses integrasi yang lebih kompleks.
Dalam melakukan integrasi tersebut, tentunya kita menginginkan kode yang diintegrasikan memenuhi standar yang ada, maka setelah kita mengcommit semua kode tersebut ke repository, ada beberapa hal yang bisa kita lakukan seperti:
- Menjalankan code style checking untuk memastikan kode memenuhi standar penulisan yang ada
- Menjalankan test untuk memastikan setiap kode yang diintegrasikan sudah berfungsi dengan baik
- Menghasilkan coverage report untuk memastikan test dilakukan secara menyeluruh
- Menjalankan analisis untuk melihat kualitas kode seperti security hotspot, code smell, dan bug dalam kode
CD: Continuous Deployment
Melakukan deployment merupakan hal yang sulit. Hal ini cukup memakan waktu. Lalu bagaimana cara kita mengatasi masalah ini? Tentunya dengan melakukan automasi deployment, sehingga kita dapat menyerahkan masalah ini ke mesin otomatis dan melanjutkan pekerjaan lainnya.
Praktek CI/CD dalam Aplikasi Nyata
Sekarang saya akan menjelaskan tentang praktek CI/CD pada kelompok pPLUKAN yang mengembangkan sebuah aplikasi web Birpen, sebuah aplikasi sistem pengumuman dan sistem surat akademik pada Fakultas Ekonomi dan Bisnis Universitas Indonesia (FEB UI)
Dalam prakteknya, CI/CD yang digunakan pada development environment, staging environment, dan production environment dapat berbeda.
- Development Environment
Pada development environment, CI/CD kelompok pepelukan memiliki dua stage, yaitu stage test dan stage analysis.
Stage pertama adalah stage Test yang meliputi dua buah Test yang berjalan secara pararel, yaitu test untuk front end dan test untuk backend, dimana pada masing-masing pekerjaan Test tersebut, dilakukan automasi linter, automasi test, dan menampilkan code coverage.
Berikut adalah snippet dari proses yang berada pada bagian UnitTestDjango
Stage kedua adalah stage analysis, dimana dilakukan analisa terhadap kode untuk mengetahui analisa kode, seperti keberadaan code smell, bug, security hotspot dan lainnya. Dalam kelompok pPLUKAN, analisis dilakukan dengan menjalankan sonarqube. Sonarqube merupakan salah satu tools yang dapat digunakan untuk melakukan analisis kode.
Dalam analysis, sonar scanner, sebuah alat untuk melakukan scan terhadap kode yang terintegrasi dengan sonarqube, dijalankan untuk meng-scan semua source code yang ditandai untuk di analisis. Kemudian hasil analisis akan diupload ke sonarqube dan dapat kita lihat hasilnya.
- Staging Environment
Pada staging environment, selain menjalankan stage dan analysis, dijalankan pula stage staging yang berisi deployment ke staging environment.
Mengenai tata cara deployment, hal ini berbeda-beda tergantung platform yang kita gunakan.
Salah satu platform yang saya gunakan untuk deployment adalah heroku, yang tata cara deploymentnya dapat dilihat di https://docs.gitlab.com/ee/ci/examples/test-and-deploy-python-application-to-heroku.html
Selain itu, environment lainnya yang juga saya gunakan untuk deployment adalah sebuah virtual machine. Untuk menghubungkan virtual machine ke repositori, kita dapat menggunakan SSH. Dalam hal ini, kita perlu mengatur RSA key yang akan digunakan untuk login ke virtual machine tanpa menggunakan password, karena saat dilakukan automasi kita tidak menginginkan adanya keperluan untuk berinteraksi dengan user seperti permintaan password. Mengenai SSH, bagi kalian yang belum mengetahui dapat mencari tahu lebih lanjut di sini, kemudian mengenai deployment menggunakan SSH pada gitlab, artikel ini sudah membahasnya dengan cukup jelas dan menarik.
Setelah login ke virtual machine, kita dapat menggunakan git untuk mengambil kode dari repository, dan menjalankan script untuk menjalankan aplikasi pada virtual machine.
- Production Environment
Perbedaan production environment dengan staging environtment hanyalah tempat deployment, tempat deployment diarahkan ke production environment
Penerapan CI/CD menggunakan Gitlab CI/CD
Dalam penerapan CI/CD, terdapat beberapa platform yang bisa dipertimbangkan seperti Travis CI, Circle CI, dan lainnya. Dalam hal ini, kelompok pPLUKAN menggunakan CI/CD yang secara default sudah terintegrasi dengan Gitlab repository, yaitu Gitlab CI/CD
Untuk menjalankan Gitlab CI/CD, kita perlu menyiapkan beberapa hal.
- Perintah CI/CD yang dijalankan pada dokumen .gitlab-ci.yml
Pada dokumen ini, kita akan mendefinisikan stage stage yang sebelumnya sudah dijabarkan
Pada penjelasan sebelumnya, kelompok pPLUKAN membagi proses integrasi ke dalam 4 stages, hal tersebut dapat didefinisikan sebagai berikut
Di dalam stage tersebut terdapat beberapa pekerjaan. Sebagai contoh pengaturan pada salah satu pekerjaan, berikut adalah pengaturan untuk bagian UnitTestDjango pada stage test.
Pada bagian ini, kita mendefinisikan beberapa hal.
- image
Hal ini merupakan docker image yang digunakan sebagai base environment dari pekerjaan ini untuk dijalankan. Dalam hal ini, karena Django bergantung dengan python, salah satu image yang bisa digunakan adalah python:3.6, yaitu image yang sudah berisi python dengan versi 3.6.
- stage
Pada bagian ini, kita mendefinisikan letak pekerjaan ini berada di stage apa.
- before_script
Lalu pada bagian before_script, hal ini adalah perintah yang akan dijalankan sebelum pekerjaan ini dimulai, dalam bagian ini kita bisa menginstall requirements requirements yang diperlukan.
Pada bagian script, hal ini berisi perintah yang akan dijalankan pada pekerjaan ini. when: on_success berarti script ini akan selalu dijalankan
- artifacts
Terkadang kita memerlukan hasil yang diperoleh dari suatu pekerjaan untuk digunakan kembali di pekerjaan yang terpisah, misal jika kita ingin menggunakan hasil coverage dari UnitTestDjango pada SonarScanner, untuk melakukan hal tersebut, kita dapat mendefinisikan artifacts, artifacts tersebut akan diupload dan dapat digunakan kembali oleh pekerjaan lainnya, kita juga dapat mendefinisikan kapan artifact tersebut akan expire pada bagian expire_in.
- only
Karena UnitTestDjango selalu dijalankan, maka kita tidak perlu mendefinisikan stage khusus dimana pekerjaan ini akan berjalan, tetapi dalam kasus seperti Deployment Staging, kita perlu mendefinisikan agar hal ini hanya berjalan di stage Staging, hal itu dapat dilakukan dengan menambahkan kode berikut
Sebagai catatan tambahan, terdapat beberapa credentials seperti username dan password database yang tidak boleh kita tuliskan secara langsung di kode .gitlab-ci.yml karena masalah sekuritas, untuk hal tersebut, Gitlab menyediakan environment variable yang dapat digunakan.
- Gitlab Runner
Kita memerlukan environment untuk menjalankan perintah-perintah yang telah didefinisikan pada dokumen .gitlab-ci.yml. Dalam hal ini, Gitlab Runner bekerja sebagai environment tersebut.
Kelompok pPLUKAN berada di bawah naungan gitlab.cs.ui.ac.id, sehingga sudah disediakan beberapa runner yang dapat digunakan secara bersama dengan pengguna lainnya di gitlab.cs.ui.ac.id, runner ini kita sebut dengan shared runner.
Namun karena manajemen shared runner diatur oleh administrator gitlab.cs.ui.ac.id, kita tidak dapat mengatasi masalah dengan cepat apabila terdapat masalah, karena harus menunggu respon dari admin. Selain itu, shared runner yang diberikan tidak cukup memenuhi kebutuhan semua pengguna gitlab.cs.ui.ac.id, sehingga terkadang terdapat antrian yang cukup lama pada runner, dan terkadang runner berjalan sangat lambat.
Untuk mengatasi masalah tersebut, kita dapat membuat runner sendiri yang caranya dapat dilihat pada dokumentasi gitlab di https://docs.gitlab.com/runner/. Runner sendiri ini kita sebut dengan runner, kelompok pPLUKAN memiliki 3 private runner.
Dengan hal-hal tersebut, Gitlab CI/CD sudah dapat bekerja dengan baik.
Penutup
Sekian pembahasan mengenai CI/CD di artikel ini. CI/CD akan sangat menghemat waktu kita karena proses-proses integrasi dan deployment dapat di automisasi, sehingga kita hanya perlu fokus mengerjakan requirements aplikasi.