Belajar GitHub Actions - Sejarah, Konsep CI/CD & Mengapa Memilih GitHub Actions

#Pendahuluan

Di episode 0 kalian sudah menyiapkan tiga fondasi skill — Git, YAML, dan bash — plus environment lengkap dengan GitHub CLI dan VS Code. Sekarang saatnya berhenti mengetik sejenak dan memahami mengapa kita semua ada di sini. Sebelum menulis workflow, kalian harus paham betul apa itu CI/CD, bagaimana tools-nya berevolusi dari server yang diurus sendiri menjadi layanan cloud-native, dan mengapa GitHub Actions menjadi pilihan yang paling masuk akal bagi tim yang sudah hidup di ekosistem GitHub.

Percaya atau tidak, kesalahan terbesar yang dilakukan pemula adalah langsung menulis YAML workflow tanpa memahami konsep dasarnya — akibatnya pipeline jadi kumpulan perintah copy-paste yang sulit dirawat. Episode ini membangun fondasi konseptual tersebut.

#Pembahasan Utama

#Apa Itu Continuous Integration (CI)?

Continuous Integration adalah praktik mengintegrasikan kode ke branch bersama (biasanya main) sesering mungkin — setiap kali ada commit atau pull request baru — dan secara otomatis menjalankan proses yang memastikan perubahan tersebut tidak merusak apa pun. Proses itu mencakup:

• Build: mengkompilasi source code menjadi artefak yang bisa dijalankan.
• Testing: menjalankan unit test, integration test, dan linting secara otomatis.
• Feedback cepat: developer tahu dalam hitungan menit apakah kodenya bermasalah, bukan menunggu sampai minggu berikutnya.

Analoginya: CI seperti checkpoint di video game. Setiap kali kamu menyelesaikan level (commit), sistem menyimpan progres dan langsung menguji apakah kamu bisa melanjutkan. Kalau gagal, kamu tahu persis di level mana harus mengulang — tanpa harus menunggu sampai akhir permainan.

Tujuan akhirnya adalah branch utama selalu hijau (green build): setiap commit di branch utama sudah pasti lolos build dan test.

#Apa Itu Continuous Delivery & Continuous Deployment (CD)?

Continuous Delivery adalah perpanjangan dari CI: setelah kode lolos semua pengujian, kode tersebut selalu siap dirilis ke produksi. Perbedaannya, perilisannya masih menunggu persetujuan manual — tim memutuskan kapan menekan tombol deploy. Ini memberi kontrol sekaligus memastikan proses rilis bisa dilakukan kapan saja tanpa drama.

Continuous Deployment mengambil satu langkah lebih jauh: setiap perubahan yang lolos pipeline otomatis di-deploy ke produksi tanpa campur tangan manusia. Persetujuan manual hanya diletakkan di tahapan yang benar-benar kritis, seperti deployment ke environment produksi.

Visualisasi alur keduanya secara sederhana:

Commit / Pull Request baru
      |
      v
CI Pipeline: build -> unit test -> lint -> code scan
      |
      v
Berhasil? ---- tidak ----> developer perbaiki & commit ulang
      |
      ya
      v
CD Pipeline: deploy staging -> E2E test -> approval gate
      |
      v
Deploy produksi / rilis versi baru

Perhatikan posisi approval gate di alur di atas: itulah pembeda utama antara Continuous Delivery (berhenti menunggu persetujuan) dan Continuous Deployment (berjalan otomatis sampai produksi).

#Evolusi Tools CI/CD

Perjalanan tools CI/CD bisa diringkas dalam tiga era:

1. Era Self-hosted (2000-an). Jenkins (awalnya bernama Hudson, lahir sekitar 2004/2005) menjadi standar industri. Kuat dan fleksibel dengan ribuan plugin, tetapi kalian bertanggung jawab penuh atas server-nya: instalasi, update, hardening keamanan, hingga scaling agent. Di tim besar, memelihara farm Jenkins adalah pekerjaan penuh waktu tersendiri.

2. Era Cloud-native (2010-an). Lahir tools CI/CD yang berjalan sebagai layanan (managed): Travis CI, CircleCI, lalu GitLab CI. Konsepnya sama seperti Jenkins — pipeline as code — tetapi server-nya diurus penyedia, dan build berjalan di runner yang bisa ditagih per menit. Tim tidak lagi sibuk memelihara server, melainkan fokus ke logika pipeline.

3. Era Integrasi Git-native (2019-sekarang). Microsoft mengakuisisi GitHub pada 2018, dan pada 2019 GitHub Actions resmi dirilis secara umum (general availability) setelah menjalani beta. Yang membedakannya bukan sekadar "CI/CD di cloud", melainkan integrasinya yang menyatu dengan setiap event repository dan lahirnya GitHub Marketplace — ekosistem action siap pakai yang bisa dibagikan antarrepository dan antartim di dunia.

#Mengapa Memilih GitHub Actions?

Ada tiga alasan utama yang membuat GitHub Actions menonjol:

1. Integrasi native dengan GitHub. Actions bukan tool yang "disambungkan" ke GitHub lewat webhook, melainkan bagian dari platform itu sendiri. Event seperti push, pull_request, issues, dan release otomatis menjadi pemicu tanpa konfigurasi tambahan. Status pipeline bahkan tampil langsung di tab Checks pada setiap pull request.

2. Ribuan action di GitHub Marketplace. Kalian tidak perlu menulis semuanya dari nol. Action populer seperti actions/checkout untuk mengkloning repository, actions/setup-node untuk mengatur runtime Node.js, atau action deploy ke Vercel — semua tinggal dipakai. Ini seperti memilih dari rak library siap pakai, lengkap dengan versioning.

3. Kuota gratis yang murah hati. Repository publik mendapat runner minutes gratis tanpa batas, dan repository privat masih mendapat kuota gratis bulanan yang cukup untuk belajar dan project kecil. Ditambah lagi model harga per-menit yang transparan tanpa biaya lisensi server.

#Perbandingan Jenkins vs GitHub Actions vs GitLab CI

Tidak ada pilihan yang salah mutlak — Jenkins tetap jago untuk kontrol penuh, GitLab CI unggul bagi tim yang ingin satu platform dari repo sampai monitoring. Tapi bagi kalian yang repository-nya sudah di GitHub, Actions menghilangkan biaya integrasi dan perawatan server, sekaligus memberi akses ke ekosistem action terbesar di dunia.

#Penutup

Pada episode 1 ini kalian telah membangun fondasi konseptual yang penting:

• Continuous Integration: automasi build, testing, dan integrasi kode di setiap commit atau pull request, demi branch utama yang selalu hijau.
• Continuous Delivery vs Continuous Deployment: siap rilis dengan approval manual versus deploy otomatis sampai produksi.
• Evolusi tools: dari Jenkins self-hosted era 2000-an, ke tools cloud-native, hingga GitHub Actions yang lahir 2019 sebagai bagian dari platform GitHub.
• Alasan memilih GitHub Actions: integrasi native dengan event GitHub, ribuan action di Marketplace, dan kuota runner gratis yang murah hati.

Sekarang kalian tahu mengapa, saatnya memahami bagaimana. Di episode 2 kita akan membedah arsitektur utama GitHub Actions: apa itu workflow, event, job, step, action, dan runner, bagaimana hubungannya satu sama lain, dan apa perbedaan GitHub-hosted runner dengan self-hosted runner. Sampai jumpa di episode 2!