Sudah hampir setahun saya menggunakan Jenkins sebagai tool/software CI Continuous Integration. Ada banyak manfaat yang saya rasakan terutama untuk mengurangi pekerjaan-pekerjaan sepele tapi berulang seperti pembuatan paket instalasi, upload updatean terbaru ke server atau deploy web api/service ke server development atau production. Dengan menggunakan software CI(Continuous Integration) seperti Jenkins pekerjaan-pekerjaan membosankan tersebut bisa dilakukan hanya dengan mengklik satu tombol atau bisa juga dibuat otomatis ketika kita mem-push perubahan source code ke repository git. Waktu yang dibutuhkan juga biasanya tidak lama sekitar 1-3 menit, ya tergantung besar atau kecilnya project yang akan dibuild/deploy.

Selain itu dari sisi dokumentasi juga ikut terbantu, karena tool seperti Jenkins dan dengan bantuan pluginnya bisa otomatis mengenerate history build dari waktu ke waktu.

Tapi pada postingan kali ini saya ingin membahas tool/software CI(Continuous Integration) yang lain yaitu GitLab CI. Beberapa hari ini saya menyempatkan untuk mencoba GitLab CI dan kesimpulannya ada beberapa kelebihan GitLab CI dibandingkan Jenkins yaitu:

• GitLab CI sudah terintegrasi dengan GitLab . GitLab adalah layanan cloud untuk repository git, jadi mirip dengan github atau bitbucket. Kelebihan gitlab dibandingkan dengan github dan bitbucket adalah untuk layanan gratisnya tidak ada pembatasan jumlah tim atau jumlah repository private yang bisa dibuat. Sedangkan untuk Jenkins repository gitnya harus diinstall terpisah atau menggunakan layanan repository git yang sudah ada seperti gitlab, github atau bitbucket.
• Konfigurasi Job di GitLab CI lebih sederhana dibandingkan Jenkins. Konfigurasi job GitLab CI menggunakan file text biasa dengan format YAML, sehingga file konfigurasi ini bisa kita tambahkan ke repository git.
• Satu konfigurasi GitLab CI sudah bisa digunakan untuk beberapa job dan stage sedangkan dengan Jenkins kita harus membuat beberapa job untuk masing-masing stage (CMIIW).
• Penggunaan Jenkins sangat cocok untuk keperluan internal kantor, jadi jika ingin digunakan secara public (di akses via internet) harus menyediakan mesin khusus yang mempunyai ip public atau bisa juga menggunakan VPS. Sedangkan untuk GitLab CI sendiri kita cukup menyediakan mesin yang mempunyai akses internet dan tidak harus mempunyai ip public.
• Apalagi ya…, silahkan dicoba sendiri he he :-D

Continuous Integration

Sebelum kita lanjut ke pembahasan GitLab CI, saya ingin mereview kembali apa yang dimaksud dengan CI (Continuous Integration). Continuous Integration, untuk selanjutnya kita sebut CI saja, merupakan salah satu kegiatan untuk meningkatkan produktivitas dalam pengembangan aplikasi di mana seluruh hasil kerja (source code) dari masing-masing developer digabungkan (push) ke dalam satu wadah (server repository source code). Bisa sekali sehari, bisa juga beberapa kali dalam sehari. Setiap penggabungan source code akan diverifikasi secara otomatis oleh server CI, yang memungkinkan tim untuk mendeteksi secara dini jika ada masalah/konflik/error pada saat penggabungan source code.

Setelah penggabungan hasil kerja (source code) selesai, server CI otomatis akan melakukan proses build untuk memastikan tidak ada kode yang merusak/membuat proses build gagal. Jadi semakin cepat kegagalan build ini diketahui semakin cepat pula kita meresponnya. Dan jika proses build-nya berhasil akan dilanjutkan dengan proses deploy. Selain itu server CI juga bisa dikonfigurasi untuk melakukan proses lain seperti menjalankan unit testing, integration testing dan testing otomatis lainnya.

Sebagai .NET developer kita sudah biasa melakukan proses build dengan menekan tombol F5 (Start Debugging) atau Ctrl+F5 (Start Without Debugging) baik pada waktu development atau perbaikan bug. Sedangkan untuk contoh deploy anggap saja seperti kita membuat paket installer yang akan didistribusikan ke komputer/server klien. Nah dengan menggunakan CI semua proses ini bisa dilakukan secara otomatis dan terpusat, sehingga kita mempunyai arsip hasil build dan deploy dari waktu ke waktu. Jadi untuk mencari file setup/paket installer terakhir enggak usah lagi nanya ke developer karena bisa langsung kita download dari server CI-nya.

Proses build ini selain bisa dibuat otomatis setiap kita mem-push source code ke server repository bisa juga kita buatkan jadwalnya, misal pas jam makan siang atau jam pulang kantor. Jadi di kantor dibuat kesepakatan/aturan klo ada yang merusak build pas jam makan siang enggak boleh makan siang sampai proses build-nya berhasil atau yang merusak build pas jam pulang kantor enggak boleh pulang sampai proses build-nya berhasil :-D

Jadi dengan menggunakan CI, alur kerja kita lebih kurang seperti berikut :

• Menulis kode, build dan tes di komputer masing-masing (seperti biasa).
• Commit dan push kode ke server repository/source control seperti GIT atau SVN.
• Server CI akan meng-clone/pull repository kemudian melakukan build, menjalankan tes otomatis (jika ada) dan deploy secara otomatis. Jika buildnya gagal ulangi lagi langkah pertama.

Nah mudah-mudahan sampai di sini sudah punya gambaran ya tentang apa itu Continuous Integration dan bagaimana cara kerjanya.

Apa saja yang perlu dipelajari ?

Untuk belajar CI, tentu saja ada pengetahun penunjang yang perlu Anda pelajari yaitu penggunaan Source/Version Control terutama GIT dan aplikasi GIT Client seperti TortoiseGit. Pengetahun lainnya adalah pembuatan paket instalasi menggunakan Inno Setup untuk aplikasi desktop atau bisa juga pengetahuan mendeploy web api/service ke server.

GitLab CI

GitLab CI adalah salah satu tool/software Continuous Integration gratis yang merupakan bagian dari GitLab. GitLab sendiri merupakan layanan cloud repository git, jadi mirip dengan github atau bitbucket. Kelebihan dari GitLab ini sendiri, untuk versi gratisnya tidak dibatasi seperti halnya github dan bitbucket. Jadi dengan versi gratisnya tidak ada pembatasan jumlah private repository yang bisa kita buat ataupun jumlah tim yang terlibat. Menarik bukan untuk sebuah layanan cloud repository git yang gratis.

GitLab CI sendiri kalo kita lihat lebih mirip dengan sebuah dashboard untuk mengelola job dan log hasil buildnya. Jadi aslinya yang melakukan build dan deploy itu bukanlah GitLab CI tapi tool lain yang disebut dengan GitLab Runner. GitLab Runner ini harus kita install di mesin (pc/server) yang mempunyai akses internet agar bisa terhubung ke service GitLab CI. Mesin untuk GitLab Runner tidak harus mempunyai ip public yang penting terkoneksi dengan internet.

Idenya sederhana tapi brilian, dengan konsep seperti ini akan menghemat resource dari server GitLab itu sendiri, karena semua resource yang dibutuhkan untuk proses build dan deploy di tanggung oleh mesin dari user/developer. Tapi dari sisi user/developer juga diuntungkan karena mesin untuk build dan deploynya adalah milik kita sendiri, sehingga kita punya akses full untuk setup/konfigurasi tool/software apa saja yang dibutuhkan untuk proses build dan deploy tersebut.

GitLab Runner

GitLab Runner adalah tool/software yang bertugas untuk menjalankan job dan mengirimkan kembali hasilnya ke GitLab, nah data-data inilah yang akan diolah oleh GitLab CI.

GitLab Runner bisa diinstall untuk GNU/Linux, macOS, FreeBSD, dan Windows.

Instalasi GitLab Runner

Instalasi GitLab Runner sendiri sangat mudah, ditambah dengan dokumentasi yang lengkap. Jadi seharusnya Anda tidak akan mendapatkan masalah untuk langkah-langkah instalasinya. Untuk petunjuknya bisa ada cek di sini.

Untuk memastikan instalasinya GitLab Runnernya berhasil, silahkan Anda cek service GitLab Runnernya.

Selain menginstall GitLab Runner, kita juga perlu menginstall beberapa tool pendukung seperti:

• .NET Framework 4.0, 4.5.x
• Microsoft Build 2015
• Source/version control Git
• Pembuat paket installer seperti Inno Setup
• Nuget untuk merestore paket nuget
• FTP Client seperti WinSCP

Intinya semua tool pendukung di atas, diinstall sesuai dengan kebutuhan environment development.

Mendaftarkan Repository ke GitLab Runner

Setelah instalasi GitLab Runner, berikutnya adalah mendaftarkan repository git ke GitLab Runner. Berikut langkah-langkahnya:

Langkah 1. Login ke GitLab, klo belum punya ya silahkan daftar terlebih dulu.

Langkah 2. Buat repository baru

Langkah 3. Setelah membuat repositorynya berhasil, klik link Settings -> Pipelines

Scroll ke bawah sedikit, kemudian catat informasi Specific Runners untuk poin 2 dan 3.

Kemudian di bagian Shared Runners klik tombol Disable shared Runners

Langkah 4. Berikutnya adalah mengaktifkan Command Prompt dengan mode Administrator kemudian masuk ke folder instalasi GitLab Runner

Setelah itu ketik perintah gitlab-runner register, kemudian tinggal jawab pertanyaan yang ada termasuk informasi Specific Runners yang kita dapatkan di langkah 3.

Jika proses registrasinya berhasil, kita bisa cek runner aktifnya dibawah informasi Specific Runners

Contoh Project

Untuk keperluan uji coba kali ini saya menggunakan contoh aplikasi Northwind yang bisa Anda download di sini. Setelah itu kita push source codenya ke link repository gitlab yang sudah kita buat di langkah-langkah sebelumnya.

Dan untuk proses push-nya saya menggunakan TortoiseGit.

Menambahkan file .gitlab-ci.yml

Untuk melakukan konfigurasi GitLab CI, kita perlu menambahkan file dengan nama .gitlab-ci.yml. File ini adalah file text biasa yang menggunakan format YAML, sehingga file konfigurasi ini bisa kita tambahkan ke folder source code kemudian kita simpan juga ke repository git.

Berikut contoh isi file .gitlab-ci.yml

Coba perhatikan skrip di atas, di baris ke-6 kita mendefinisikan beberapa stage yaitu restore dan build, kita bisa juga menambahkan stage yang lain misal test, deploy, development, production, dst. Stage digunakan untuk menentukan jenis dari job. Jadi perlu diingat bahwa stage dan job itu berbeda, walaupun dibanyak contoh menggunakan nama yang sama untuk stage dan job.

Eksekusi antar job di GitLab CI itu sifatnya independen atau dengan kata lain tidak ada hubungan antar job. Ketika job B membutuhkan file yang dihasilkan oleh job A secara default tidak bisa, sehingga kita perlu menambahkan konfigurasi cache, seperti yang terlihat di baris ke-10. Kita mendaftarkan folder lib ke dalam konfigurasi cache. Folder lib ini berisi file-file library (*.dll) hasil dari job restore_nuget_package. Semua file yang ada di folder lib ini dibutuhkan pada saat menjalankan job build_solution.

Berikutnya kita pindah ke baris 15, di baris ini kita mendefinisikan job dengan nama restore_nuget_package dengan tipe stage restore, kemudian menjalankan skrip untuk merestore paket nuget.

Terakhir di baris ke-21, kita mendefinisikan job lain dengan nama build_solution, sesuai namanya job ini digunakan untuk membuild solution atau project atau klo lewat IDE Visual Studio .NET kita menekan tombol F5 (Start Debugging) atau Ctrl+F5 (Start Without Debugging).

Cara Mengecek/Memvalidasi Skrip File .gitlab-ci.yml

Sebelum kita menambahkan file .gitlab-ci.yml ke repository git, ada baiknya kita cek terlebih dahulu apakah script yang kita tuliskan sudah benar atau belum. GitLab CI sudah menyediakan link khusus untuk mengeceknya, yang bisa Anda cek di sini.

Testing Build

Untuk testing build kita tinggal melakukan push ke repository git.

Kemudian untuk melihat log progres buildnya kita bisa cek link Pipelines.

Gambar detail job yang sedang dijalankan

Untuk melihat detail log dari masing-masing job, tinggal kita klik nama jobnya, misal job restore nuget package

job build solution

Status proses build berhasil

Untuk contoh lengkap hasil buildnya bisa Anda cek di sini

Akhirnya selesai juga postingan GitLab CI untuk .NET Developer Bagian #1, dan mudah-mudahan bisa dipahami :-D. Untuk postingan berikutnya insyaAlloh kita akan menambahkan job untuk membuat paket instalasi menggunakan Inno Setup dan menguploadnya sehingga bisa langsung didownload via Dashboard GitLab CI.

Selamat MENCOBA :-)