Gitlab CI/CD — Improve Your Deployment Workflow

sumber: https://about.gitlab.com/product/continuous-integration/

Artikel ini dibuat sebagai bagian dari Individual Review PPL 2021

Ilustrasi Permasalahan

Apabila kita melihat sejarah perkembangan deployment aplikasi dari zaman ke zaman, terdapat perbedaan yang signifikan antara bagaimana aplikasi tersebut di-deploy. Aplikasi (dalam hal ini web application) yang dikembangkan pada beberapa puluh tahun lalu cenderung statis dan rilis dalam waktu yang cukup lama. Deployment hanya dilakukan beberapa kali saja dan biasanya harus dilakukan lewat SSH dan dibantu dengan shell script yang cukup sederhana. Cara ini sebenarnya bisa saja berjalan dengan mudah untuk aplikasi yang sederhana. Namun, seiring dengan perkembangan microservice dan kompleksnya aplikasi cara ini sangat sulit diterapkan. Berikut ini adalah permasalahan-permasalahan yang harus dihadapi:

• Memastikan agar dependencies yang digunakan saat berada di local dan remote computer tidak sampai mengalami konflik.
• Rilis aplikasi menjadi hal yang cukup menakutkan dan jarang dilakukan. Hal ini karena ada beberapa hal pada deployment yang masih dilakukan manual dan terkadang rawan akan masalah.

Seiring dengan perkembangan microservice dan agile manifesto, muncul cara automatic deployment yang bisa dilakukan dengan mudah. Salah satunya yaitu Gitlab CI/CD.

CI/CD

Sebelum mulai, kita perlu mengetahui tentang konsep CI/CD terlebih dahulu. CI/CD merupakan singkatan dari Continuous Integration, Continuous Delivery dan Continuous Deployment yang memiliki arti sebagai berikut:

• Continuous Integration, merupakan sebuah proses untuk melakukan Test dan Build secara manual ataupun otomatis setiap kali ada commit baru didalam repository.
• Continuous Delivery, merupakan proses untuk melakukan Continuous Integration (CI), automated testing, serta automated deployment ketika ada commit baru didalam repository.
• Continuous Deployment, merupakan proses deployment sistem ke production secara otomatis. Sehingga tidak perlu lagi ada intervensi dari manusia.

sumber: https://blogs.cisco.com/cloud/have-you-ever-considered-ci-cd-as-a-service

Berdasarkan hal-hal tersebut dapat kita tangkap bahwa tujuan utama dari CI/CD adalah untuk membuat siklus rilis dari suatu aplikasi yang sangat cepat. Developer tidak perlu lagi menetapkan jadwal serta penetapan versi untuk rilis suatu aplikasi. Rilis aplikasi dapat dilakukan setiap kali ada perubahan yang telah diuji keabsahannya terlebih dahulu. Dengan kata lain, rilis aplikasi dilakukan secara Rolling Release. Contoh penerapan rilis aplikasi seperti ini sudah diterapkan pada banyak web application terutama pada microservice.

Gitlab CI

Gitlab CI merupakan salah satu dari banyak alat yang bisa digunakan untuk CI/CD. Dalam penerapannya, terdapat suatu pipeline yang akan menggunakan konfigurasi CI untuk melakukan automisasi proses dari CI/CD. Pada gitlab, konfigurasi ini dapat dilakukan melalui file .gitlab-ci.yml yang terletak pada setiap project Gitlab. Setiap kali terjadi push pada kode, file ini akan membuat pipeline yang terdiri dari satu atau banyak tahap. Pipeline ini pun akan dijalankan oleh Runner yang akan melakukan perubahan CI/CD.

Implementasi pada PPL

Dalam PPL 2021, kelompok kami “funtech” menggunakan Gitlab CI/CD untuk seluruh integrasi yang ada. Pada proyek ini, terdapat dua repositori untuk bagian frontend dan backend. Artikel ini akan membahas lebih jauh untuk repositori pada frontend. Berikut ini adalah potongan-potongan file konfigurasi pada .gitlab-ci.yml :

image: node:latest

stages:
  - test
  - lint
  - sonar
  - deploy

Pada konfigurasi pada CI/CD kali ini terdapat 4 tahap yang akan dilakukan, yaitu test, lint, sonar, dan deploy. Untuk tahap deploy hanya akan dijalankan pada branch staging dan master saja. Perlu diamati image yang akan digunakan adalah node (Node.js) yang diperlukan untuk menjalankan React.

test:
  stage: test
  
  before_script:
    - apt-get update -qy
    - apt-get install -y ruby-dev
    - gem install dpl
  
  script:
    - npm install
    - npm run test -- --coverage --watchAll=false

Pada tahap pertama ini akan dijalankan instalasi untuk dependencies yang ada dan dijalankan testing serta ditampilkan coverage yang ada.

eslint:
  stage: lint
  
  script:
    - npm install eslint eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react prettier eslint-config-prettier eslint-plugin-prettier husky lint-staged eslint-plugin-compat
    - npm run lint

Tahap kedua akan dilakukan pengecekan linter yang dengan menggunakan konfigurasi eslint yang telah ada pada repositori.

# Sonarqube Implementation
SonarScanner Dev:
  image:
    name: sonarsource/sonar-scanner-cli:4.6
    entrypoint: [ "" ]

  stage: sonar
  script:
  - sonar-scanner
    -Dsonar.host.url=https://pmpl.cs.ui.ac.id/sonarqube
    -Dsonar.login=$SONARQUBE_TOKEN
    -Dsonar.projectKey=$SONARQUBE_PROJECT_KEY
    -Dsonar.branch.name=$CI_COMMIT_REF_NAME
    -Dsonar.branch.target=staging
  except:
    - master
    - staging

SonarScanner:
  image:
    name: sonarsource/sonar-scanner-cli:4.6
    entrypoint: [ "" ]

  stage: sonar
  script:
    - sonar-scanner
      -Dsonar.host.url=https://pmpl.cs.ui.ac.id/sonarqube
      -Dsonar.login=$SONARQUBE_TOKEN
      -Dsonar.projectKey=$SONARQUBE_PROJECT_KEY
      -Dsonar.branch.name=$CI_COMMIT_REF_NAME
  only:
    - master
    - staging

# Sonarqube implementation end

Pada tahap ketiga yaitu sonar, terdapat dua jenis konfigurasi yang berbeda untuk sonarqube. Terdapat konfigurasi SonarScanner Dev yang dijalankan pada branch PBI maupun Coldfix dan terdapat konfigurasi SonarScanner yang dijalankan pada branch master dan staging.

staging:
  stage: deploy
  image: ruby:latest


  before_script:
    - apt-get update -qy
    - apt-get install -y ruby-dev
    - gem install dpl
    
  script:
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY
  only:
    - staging
  environment:
    name: staging

production:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - echo $CI_BUILD_TOKEN | docker login -u $CI_REGISTRY_USER --password-stdin $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE -f Dockerfile .
    - docker push $CI_REGISTRY_IMAGE
  only:
    - master
  environment:
    name: production

Pada tahap terakhir yaitu deploy, terdapat dua konfigurasi yang berbeda pada branch staging dan master. Perbedaan dari konfigurasi tersebut ialah pada branch staging menggunakan heroku sebagai platform untuk deployment sedangkan pada branch master menggunakan docker langsung untuk di-deploy pada Azure. Mungkin hal ini tidak terlihat jelas pada konfigurasi ini, karena terdapat cukup banyak environment variable yang seperti $CI-REGISTRY_IMAGE . Untuk mengetahui ataupun mengubah nilai dari environment variable tersebut kita bisa buka menu gitlab Settings -> CI/CD -> Variables.

Selain itu, ketika menjalankan CI/CD gitlab otomatis akan menghentikan Pipeline apabila salah satu tahap saja gagal seperti berikut:

contoh gagal

Dengan CI/CD kita ditekankan agar setidaknya dapat melewati seluruh stage yang ada untuk menghindari masalah yang telah ditangkap.

Demikian artikel ini, penggunaan gitlab CI/CD mempermudah agar Developer lebih fokus pada aplikasi yang dikembangkan. Untuk urusan deployment dan konfigurasi CI cukup dilakukan pada tahap awal pengembangan saja.

Adrian

Referensi:

• https://medium.com/dot-intern/integrasi-gitlab-ci-cd-dengan-heroku-pada-aplikasi-reactjs-188dfa4be35c
• https://docs.gitlab.com/ee/ci/