Our gitlab-ci.yum

Photo by NASA on Unsplash

Continuous Integration (CI) adalah praktik pengembangan software dimana anggota tim mengintegrasikan pekerjaan mereka secara rutin. Dengan bantuan version control, integrasi kode biasanya dilakukan oleh scripting untuk menguji kesuksesan build (compiling source code), menguji kebenaran source code dengan testing, dan akhirnya meluncurkan aplikasi ke publik. CI diakui oleh banyak tim developer di seluruh dunia dapat meningkatkan efisiensi dalam pengecekan source code dan peluncuran aplikasi karena semuanya dilakukan secara otomatis dengan runner.

Pada PPL 2019, kami menggunakan fitur CI pada repository Gitlab kami untuk mempermudah automasi compiling hingga deploy aplikasi. Gitlab mewajibkan developer menuliskan sebuah file YAML bernama gitlab-ci.yml yang memiliki sintaks-sintaks yang harus diikuti. Seluruh sintaks dan semantiks yang bisa ditulis dalam gitlab-ci.yml terdapat disini.

Bagaiamanakah bentuk dari CI kelompok PPL kami?

stages:
  — build
  — test
  — deploy

Di bagian pertama ada label stages yang menentukan tahapan apa saja yang harus dilewati source code selama CI berjalan. Kami mengikuti format standar untuk NodeJS yakni build, test, dan akhirnya deploy.

variables:
HTTP_PROXY: http://proxy.cs.ui.ac.id:8080
 HTTPS_PROXY: http://proxy.cs.ui.ac.id:8080
 FTP_PROXY: http://proxy.cs.ui.ac.id:8080
 NO_PROXY: “localhost,127.0.0.1,gitlab.cs.ui.ac.id,docker:2375,docker:2376”
 DOCKER_HOST: tcp://docker:2375
 DOCKER_DRIVER: overlay2
 ENVIRONMENT: GITLAB

Bagian berikutnya ada label variables yang menentukan local variabel yang bisa digunakan dalam file ini. Jika terdeteksi string yang sama dengan variabel di atas, string tersebut akan diganti dengan value yang berpasangan dengan key nya. Keep in mind kami menaruh beberapa variabel proxy karena kami akan menggunakan jasa registry milik Fasilkom dan container manager di server Fasilkom jadi kami harus memberitahu gitlab runner kalau kami punya proxy untuk bypass firewall server Fasilkom.

Build:
 image : node:latest
 stage : build
 script:
   — npm run build

Nah mulai dari sini kami mulai menentukan Job yang harus CI lakukan. File YAML mendefinisikan satu set job dengan constraints yang menyatakan kapan mereka harus dijalankan. Tugas kita untuk memberitahu dalam tiap job apa saja yang harus dilakukan. Kira-kira penjelasan potongan script diatas adalah:

• Build adalah judul job. Programmer bebas memberi nama job dengan pengecualian beberapa reserved words: image, services, stages, types, before_script, after_script, variables, cache.
• image adalah template OS Linux. Secara singkat, runner berjalan di atas OS Linux dengan komponen software yang dinyatakan di value image. Jika imagenya node:latest, maka gitlab runner harus menggunakan Image Linux yang memilki software-software yang cukup untuk menjalankan NodeJS.
• Stage: build artinya job ini dijalankan dengan label build untuk memudahkan labelling di Gitlab CI.
• Pada akhirnya, Script biasa dipakai untuk melakukan command-command yang perlu untuk melakukan build. Kalau bingung, bayangkan saja isinya script adalah command-command yang kamu harus ketik di terminal sistem kamu untuk menngcompile source code kamu. Tentu saja harus mengikuti kaidah dari framework yang kamu pakai juga. Pada kasus kami, karena kami menggunakan NodeJS, kami menggunakan command npm run build untuk menjalankan sub-script “build” yang terdefinisi di file package.json kami. Isinya package.json nya panjang, jadi singgah di repo kami saja ya!

Staging_Deployment:
 image: docker:stable
 stage: deploy
 only:
   — staging
 services:
   — docker:dind
 before_script:
   — docker info
 script:
   — docker login -u $LDAP_USERNAME -p $LDAP_PASSWORD registry.docker.ppl.cs.ui.ac.id
   — docker build -t registry.docker.ppl.cs.ui.ac.id/ppld7/happyfresh-staging:latest .
   — docker push registry.docker.ppl.cs.ui.ac.id/ppld7/happyfresh-staging:latest

Bagian terakhir adalah job untuk men-deploy aplikasi kami. Keep in mind kami memanfaatkan Docker untuk menjalankan server kami, sehingga yang harus kami lakukan adalah build sebuah image baru lalu meng-upload image tersebut ke Registry Docker milik Fasilkom; agar disimpan secara privat thanks PPL! Yang perlu dilakukan adalah login terlebih dahulu ke registry Fasilkom dengan authentication. Value LDAP_* diambil dari Gitlab secret keys agar menjaga kerahasiaan SSO UI anggota tim. Berikutnya menyuruh Docker membuat image Docker dengan tag happyfresh-staging:latest. Pemberian tag selalu berguna untuk memudahkan developer push dan pull image kesana dan kesini. Definisi membangun image ditulis dalam Dockerfile yang developer harus sudah tulis dan uji keberhasilannya di lokal. Yang terakhir, gitlab runner mengupload image tersebut ke registry Fasilkom. Nanti container yang mengandung image tersebut harus pull lagi image tersebut untuk meng-update aplikasi

Tidak semua bagian script gitlab-ci.yml saya tampilkan, namun kira-kira begitulah automasi CI kelompok kami selama PPL. Inovasi continuous integration sungguh memudahkan developer mendeliver aplikasinya secara cepat dan tepat. Dan perlu diingat bahwa CI tidak dimiliki oleh gitlab saja, begitu kita memakai layanan repo dan CI yang lain, tentu saja kita harus belajar sintaks-sintaks yang berbeda untuk mendefinisikan Build-Test-Deploy.

Benny William Pardede

Koneg Liquid Devops