Membuat Pipeline CI/CD Sederhana dengan GitHub Actions

Foto oleh cottonbro studio via Pexels

Membuat Pipeline CI/CD Sederhana dengan GitHub Actions

Dalam pengembangan perangkat lunak modern, kecepatan dan keandalan adalah kunci. Apakah Anda masih melakukan proses build aplikasi secara manual setiap kali ada perubahan kode? Atau mungkin sering terlambat menyadari bug karena integrasi kode baru dari berbagai developer belum terverifikasi dengan cepat? Jika ya, Anda berada di jalur yang tepat untuk mengenal Continuous Integration (CI).

Pada artikel sebelumnya, kita sudah membahas pengenalan CI/CD secara fundamental. Sekarang, saatnya melangkah lebih jauh dan mengimplementasikannya secara praktis. Salah satu platform CI/CD yang paling populer dan terintegrasi penuh dengan ekosistem Git adalah GitHub Actions. Artikel ini akan memandu Anda membuat pipeline Continuous Integration (CI) sederhana untuk memastikan kode aplikasi Anda selalu bisa di-build tanpa masalah.

Apa Itu GitHub Actions?

GitHub Actions adalah fitur platform CI/CD yang disediakan langsung oleh GitHub. Ia memungkinkan Anda untuk mengotomatisasi, mengkustomisasi, dan mengeksekusi alur kerja pengembangan perangkat lunak langsung dari repositori GitHub Anda. Mulai dari build, test, hingga deploy aplikasi, semuanya bisa dikelola dengan konfigurasi berbasis YAML.

Konsep Dasar dalam GitHub Actions

Sebelum kita mulai menulis kode, mari pahami beberapa terminologi penting dalam GitHub Actions:

  • Workflow: Ini adalah proses otomatis yang Anda definisikan. Sebuah workflow terdiri dari satu atau lebih job. File workflow disimpan dalam format YAML di direktori .github/workflows/.
  • Event: Pemicu yang memulai sebuah workflow. Contohnya adalah push ke sebuah branch, pull request dibuka, atau jadwal tertentu.
  • Job: Sekumpulan langkah (steps) yang dieksekusi pada runner yang sama. Secara default, job berjalan secara paralel, tetapi Anda bisa mengaturnya agar berjalan secara sekuensial.
  • Step: Sebuah tugas individual dalam sebuah job. Step bisa berupa menjalankan perintah shell (run) atau menggunakan sebuah action (uses).
  • Action: Unit kerja yang bisa digunakan kembali. Action dapat berupa script atau Docker container yang dibuat oleh komunitas atau GitHub sendiri (misalnya, actions/checkout, actions/setup-dotnet).
  • Runner: Server tempat job dieksekusi. GitHub menyediakan runner yang di-host (Ubuntu, Windows, macOS) atau Anda bisa menggunakan runner Anda sendiri (self-hosted runner).

Skenario Praktis: Build Aplikasi .NET Core Sederhana

Untuk demonstrasi, bayangkan Anda memiliki sebuah aplikasi web sederhana berbasis ASP.NET Core dengan struktur direktori sebagai berikut:

  • MyProject/ (root folder)
    • .github/
      • workflows/ (folder tempat file workflow GitHub Actions berada)
    • MyWebApp/ (folder proyek aplikasi web Anda)
      • MyWebApp.csproj
      • Program.cs
    • MyProject.sln (file solusi Visual Studio)

Tujuan kita adalah membuat pipeline CI yang secara otomatis akan:

  1. Mengecek keluar (checkout) kode dari repositori.
  2. Menyiapkan lingkungan .NET SDK.
  3. Melakukan restore dependensi proyek.
  4. Melakukan build proyek untuk memastikan tidak ada kesalahan kompilasi.
Ini adalah langkah krusial dalam Continuous Integration, memastikan setiap perubahan kode yang digabungkan ke branch utama selalu dalam keadaan yang bisa di-build.

Membuat Workflow GitHub Actions Pertama Anda

Proses pembuatan workflow ini cukup lugas:

  1. Buat Direktori Workflow: Di root repositori Anda, buatlah folder .github/workflows/. Ini adalah lokasi standar untuk semua file workflow GitHub Actions Anda.
  2. Buat File YAML: Di dalam direktori .github/workflows/, buat sebuah file baru, misalnya simple-build.yml. Nama file ini bisa apa saja, asalkan berekstensi .yml atau .yaml.
  3. Tulis Konfigurasi Workflow: Masukkan kode YAML berikut ke dalam file simple-build.yml Anda:

File Workflow GitHub Actions: simple-build.yml

name: Simple .NET Build CI on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # Agar Git History bisa diakses oleh actions lain jika dibutuhkan - name: Setup .NET uses: actions/setup-dotnet@v4 with: dotnet-version: '8.x' # Atau versi yang sesuai dengan proyek Anda - name: Restore dependencies run: dotnet restore MyWebApp/MyWebApp.csproj # Ganti dengan path proyek Anda - name: Build project run: dotnet build MyWebApp/MyWebApp.csproj --no-restore # --no-restore agar tidak restore ulang

Mari kita bedah setiap bagian dari file konfigurasi ini:

  • name: Simple .NET Build CI: Nama dari workflow Anda yang akan muncul di antarmuka GitHub Actions.
  • on:: Mendefinisikan kapan workflow ini akan dieksekusi. Dalam contoh ini, workflow akan berjalan ketika ada push atau pull request ke branch main.
  • jobs:: Sekumpulan pekerjaan yang akan dijalankan. Di sini kita memiliki satu job bernama build.
  • build:: Nama unik untuk job ini.
  • runs-on: ubuntu-latest: Menentukan jenis runner yang akan digunakan. ubuntu-latest berarti runner Linux versi terbaru yang di-host oleh GitHub.
  • steps:: Daftar langkah-langkah yang akan dieksekusi dalam job build secara berurutan.
    • - uses: actions/checkout@v4: Ini adalah action resmi dari GitHub yang bertanggung jawab untuk mengambil (checkout) kode dari repositori ke dalam runner. @v4 menunjukkan versi action yang digunakan. fetch-depth: 0 memastikan semua riwayat Git diambil, yang mungkin berguna untuk action selanjutnya atau jika Anda perlu melakukan operasi Git.
    • - name: Setup .NET & uses: actions/setup-dotnet@v4: Action ini menginstal .NET SDK versi 8.x (atau versi lain yang Anda tentukan) di runner, sehingga perintah dotnet bisa digunakan.
    • - name: Restore dependencies & run: dotnet restore MyWebApp/MyWebApp.csproj: Langkah ini menjalankan perintah dotnet restore untuk mengunduh semua paket NuGet yang dibutuhkan proyek Anda. Pastikan untuk mengganti MyWebApp/MyWebApp.csproj dengan jalur proyek yang sesuai di repositori Anda.
    • - name: Build project & run: dotnet build MyWebApp/MyWebApp.csproj --no-restore: Langkah terakhir ini menjalankan perintah dotnet build untuk mengkompilasi proyek Anda. Flag --no-restore digunakan karena kita sudah melakukan restore di langkah sebelumnya, menghindari duplikasi pekerjaan.

Menjalankan dan Memantau Pipeline Anda

Setelah file simple-build.yml Anda disimpan dan di-push ke repositori GitHub (ke branch main atau buat pull request ke main), GitHub Actions akan secara otomatis mendeteksi perubahan tersebut dan menjalankan workflow Anda.

Untuk memantau eksekusi workflow:

  1. Navigasi ke repositori Anda di GitHub.
  2. Klik tab Actions.
  3. Anda akan melihat daftar workflow yang berjalan atau sudah selesai. Klik pada nama workflow Anda (misalnya, Simple .NET Build CI) dan kemudian klik pada eksekusi spesifik yang ingin Anda lihat log-nya.
  4. Anda bisa melihat setiap step berjalan dan log output-nya secara real-time.

Jika semua berjalan lancar, Anda akan melihat tanda centang hijau di samping setiap step dan job, menandakan bahwa build berhasil:

Contoh Tampilan Workflow yang Berhasil di GitHub Actions UI

Simple .NET Build CI / build Job build (ID: ...) started Set up job Run actions/checkout@v4 ... (checkout logs) Run actions/setup-dotnet@v4 ... (dotnet setup logs) Run dotnet restore MyWebApp/MyWebApp.csproj ... (dotnet restore output, e.g., 'Restored MyWebApp.csproj (8.x) in 1.23 sec.') Run dotnet build MyWebApp/MyWebApp.csproj --no-restore ... (dotnet build output, e.g., 'Build succeeded.', '0 Warning(s)', '0 Error(s)') Job build completed successfully

Apabila ada kesalahan, Anda akan melihat tanda silang merah. Klik pada step yang gagal untuk melihat log detail yang akan membantu Anda mengidentifikasi masalahnya, misalnya kesalahan kompilasi atau dependensi yang hilang.

Trade-off dan Batasan GitHub Actions Sederhana

Meskipun GitHub Actions sangat kuat, penting untuk memahami kapan ia paling cocok dan kapan mungkin ada solusi alternatif:

  • Proyek GitHub: GitHub Actions terintegrasi paling baik dengan repositori GitHub. Jika Anda menggunakan platform Git lain (misalnya GitLab, Bitbucket), Anda mungkin akan lebih efektif menggunakan solusi CI/CD bawaan mereka (misalnya GitLab CI/CD, Bitbucket Pipelines).
  • Kustomisasi Lanjut: Untuk alur kerja yang sangat kompleks dengan kebutuhan infrastruktur khusus (misalnya, mesin build dengan spesifikasi sangat tinggi, atau integrasi mendalam dengan sistem on-premise yang unik), Anda mungkin perlu mengevaluasi solusi lain seperti Jenkins atau Azure DevOps yang menawarkan fleksibilitas konfigurasi infrastruktur lebih. Namun, GitHub Actions terus berkembang dan mendukung self-hosted runner untuk skenario ini.
  • Batasan Free Tier: GitHub Actions menyediakan free tier yang cukup murah hati untuk proyek publik dan batas tertentu untuk proyek privat. Untuk penggunaan skala sangat besar, biaya mungkin menjadi pertimbangan.

Kesalahan Umum dalam Mengonfigurasi GitHub Actions

Beberapa kesalahan yang sering dilakukan developer pemula saat mengonfigurasi GitHub Actions:

  • Inden YAML yang Salah: YAML sangat sensitif terhadap inden (spasi). Kesalahan inden dapat menyebabkan workflow gagal di-parse. Gunakan editor yang mendukung validasi YAML.
  • Lupa actions/checkout: Tanpa action ini, kode repositori Anda tidak akan tersedia di runner, sehingga langkah build atau test akan gagal menemukan file proyek.
  • Versi SDK/Dependensi yang Tidak Sesuai: Pastikan versi .NET SDK (atau Node.js, Python, dll.) yang Anda tentukan di action setup-dotnet (atau sejenisnya) sesuai dengan kebutuhan proyek Anda.
  • Jalur Proyek (Path) yang Salah: Jika proyek Anda tidak berada di root repositori, pastikan Anda menentukan jalur yang benar dalam perintah dotnet restore atau dotnet build.

Ringkasan dan Langkah Selanjutnya

Selamat! Anda telah berhasil membuat pipeline Continuous Integration sederhana menggunakan GitHub Actions. Anda telah belajar bagaimana mendefinisikan workflow, job, dan steps untuk secara otomatis melakukan build aplikasi Anda setiap kali ada perubahan kode.

Pipeline CI sederhana ini adalah fondasi yang sangat penting. Dengan ini, Anda mendapatkan umpan balik instan tentang status kompilasi kode Anda. Namun, ini hanyalah permulaan. Langkah selanjutnya dalam perjalanan CI/CD adalah menambahkan Automated Testing ke dalam pipeline untuk memastikan tidak hanya kode bisa di-build, tetapi juga berfungsi dengan benar. Setelah itu, kita akan membahas cara mengintegrasikan deployment otomatis.

Seri Belajar Git & CI/CD:

← Sebelumnya: Pengenalan CI/CD untuk Developer

→ Selanjutnya: Automated Testing dalam Pipeline CI/CD