Membangun CI/CD yang Efisien untuk Monorepo: Strategi dan Tooling untuk Skala Besar

1. Pendahuluan

Monorepo, atau repositori tunggal yang menampung banyak proyek kode, telah menjadi pilihan arsitektur yang populer di banyak tim pengembangan, dari startup hingga perusahaan besar. Konsepnya sederhana: daripada memiliki puluhan atau ratusan repositori terpisah untuk setiap microservice, frontend, atau library, semuanya dikumpulkan dalam satu tempat. ✅

Manfaatnya banyak: berbagi kode lebih mudah, konsistensi versi dependensi terjaga, dan refactoring lintas proyek menjadi lebih aman. Namun, ketika berbicara tentang Continuous Integration/Continuous Delivery (CI/CD), monorepo bisa menjadi pedang bermata dua.

Bayangkan Anda memiliki monorepo dengan 50 proyek di dalamnya. Setiap kali ada developer melakukan perubahan kecil pada satu baris kode di satu proyek, apakah Anda harus membangun ulang, menguji, dan bahkan me-deploy semua 50 proyek? Tentu saja tidak! Itu akan sangat memakan waktu, boros sumber daya, dan memperlambat feedback loop developer. ⚠️

Artikel ini akan membawa Anda menyelami tantangan CI/CD di lingkungan monorepo dan, yang terpenting, bagaimana mengatasinya. Kita akan membahas strategi cerdas dan tooling praktis untuk membangun pipeline CI/CD yang efisien, cepat, dan hemat biaya, bahkan untuk monorepo skala besar. Mari kita jadikan CI/CD di monorepo bukan lagi momok, melainkan akselerator produktivitas! 🚀

2. Tantangan CI/CD di Lingkungan Monorepo

Sebelum kita membahas solusinya, mari kita pahami dulu mengapa CI/CD di monorepo seringkali terasa seperti memanjat tebing terjal:

2.1. Waktu Build dan Testing yang Panjang ⏳

Ini adalah keluhan paling umum. Jika pipeline CI/CD Anda dirancang untuk monorepo tradisional (yang tidak sadar monorepo), setiap perubahan kecil di branch manapun akan memicu proses build dan testing untuk semua proyek di dalam repositori.

Analogi: Bayangkan Anda punya pabrik besar yang memproduksi berbagai jenis mobil. Jika ada perubahan desain kecil pada satu jenis lampu mobil, apakah Anda akan menghentikan seluruh jalur produksi dan merakit ulang semua jenis mobil dari awal? Tentu tidak! Anda hanya akan mengubah jalur produksi untuk lampu mobil tersebut. CI/CD monorepo yang tidak efisien seperti pabrik yang merakit ulang semua mobil.

2.2. Konsumsi Sumber Daya Berlebihan 💸

Menjalankan build dan ribuan, bahkan puluhan ribu, unit dan integrasi tes untuk semua proyek setiap saat membutuhkan banyak CPU, memori, dan storage. Ini berarti biaya yang lebih tinggi untuk runner CI/CD Anda, baik di cloud maupun on-premise.

2.3. Kompleksitas Konfigurasi Pipeline 😵‍💫

Mengelola konfigurasi CI/CD untuk banyak proyek dalam satu file atau beberapa file yang tidak terstruktur bisa menjadi mimpi buruk. Bagaimana Anda memastikan setiap proyek memiliki langkah build, test, dan deploy yang benar tanpa membuat file konfigurasi yang raksasa dan sulit dibaca?

2.4. Feedback Loop Lambat untuk Developer 🐢

Ketika pipeline CI/CD membutuhkan waktu puluhan menit atau bahkan jam untuk selesai, developer akan menunggu lebih lama untuk mendapatkan feedback apakah perubahan mereka merusak sesuatu. Ini mengurangi produktivitas dan dapat menyebabkan frustrasi.

Melihat tantangan ini, jelas bahwa kita membutuhkan pendekatan yang lebih cerdas. Kuncinya adalah membuat pipeline CI/CD kita “sadar monorepo” (monorepo-aware).

3. Strategi Kunci: Selective Builds & Testing

Strategi paling fundamental untuk CI/CD monorepo yang efisien adalah Selective Builds & Testing. Konsepnya sederhana: hanya jalankan proses CI/CD untuk proyek-proyek yang benar-benar terpengaruh oleh sebuah perubahan.

3.1. Bagaimana Mendeteksi Perubahan yang Relevan?

Untuk menerapkan selective builds, kita perlu mengetahui:

Proyek mana yang berubah? Ini bisa dideteksi dengan membandingkan file yang berubah antara current branch dan base branch (misalnya main atau master).
Proyek mana yang bergantung pada proyek yang berubah? Jika Anda mengubah sebuah library utilitas, semua proyek yang menggunakan library tersebut juga berpotensi terpengaruh dan harus di-build/test ulang. Ini membutuhkan pemahaman tentang dependency graph monorepo Anda.

📌 Tips: Git adalah teman terbaik Anda di sini. Anda bisa menggunakan git diff untuk mengetahui file apa saja yang berubah. Namun, mengurai dependency graph secara manual akan sangat sulit.

3.2. Tooling untuk Selective Builds & Testing

Inilah mengapa Monorepo Management Tools seperti Nx dan Turborepo sangat powerful. Mereka dirancang khusus untuk memahami struktur monorepo Anda, membangun dependency graph antar proyek, dan secara cerdas mendeteksi proyek mana yang “terpengaruh” oleh sebuah perubahan.

Contoh dengan Nx:

Misalkan Anda memiliki monorepo dengan aplikasi frontend my-app dan library ui-lib. Jika Anda mengubah kode di ui-lib, Nx dapat mendeteksi bahwa my-app menggunakan ui-lib, sehingga my-app juga perlu di-build dan diuji.

# Perintah untuk menjalankan tes hanya pada proyek yang terpengaruh
nx affected --target=test

# Perintah untuk membangun hanya proyek yang terpengaruh
nx affected --target=build

# Perintah untuk menjalankan E2E tests hanya pada proyek yang terpengaruh
nx affected --target=e2e

Dengan perintah nx affected, Anda memberi tahu Nx untuk hanya menjalankan target (misalnya test atau build) pada proyek yang berubah atau proyek yang bergantung pada perubahan tersebut. Ini adalah game changer untuk mempercepat pipeline CI/CD Anda! 🚀

4. Memanfaatkan Caching untuk Kecepatan Super

Setelah selective builds, langkah selanjutnya adalah caching. Jika Anda sudah membangun atau menguji sebuah proyek dengan input yang sama sebelumnya, mengapa harus melakukannya lagi?

4.1. Konsep Caching Output

Monorepo tools seperti Nx dan Turborepo memiliki computation cache. Ini berarti mereka menyimpan hasil dari setiap operasi (build, test, lint) yang berhasil dijalankan. Jika Anda mencoba menjalankan operasi yang sama dengan input (kode, konfigurasi, dependensi) yang sama, mereka akan langsung mengembalikan hasil dari cache, tanpa perlu menjalankan ulang.

Analogi: Anda membuat kue. Setelah selesai, Anda menyimpan resep dan juga hasil kuenya. Jika besok Anda ingin kue yang sama persis, Anda tinggal mengambil kue yang sudah jadi dari kulkas (cache), bukan membuat ulang dari awal.

4.2. Remote Caching: Berbagi Cache Antar Tim

Yang lebih hebat lagi adalah remote caching. Hasil cache tidak hanya disimpan di mesin lokal Anda atau runner CI/CD, tetapi juga bisa dibagikan ke server terpusat.

Manfaat Remote Caching:
- Developer Lokal: Jika rekan tim Anda baru saja membangun my-app, Anda bisa mendapatkan hasil build-nya dari remote cache tanpa perlu build di mesin Anda.
- Runner CI/CD: Jika sebuah branch lain sudah menjalankan build/test untuk suatu proyek, runner CI/CD Anda bisa langsung mengambil hasilnya dari remote cache.

Remote caching secara drastis mengurangi waktu build dan test, karena banyak operasi yang tidak perlu dijalankan sama sekali!

Contoh Implementasi:

Baik Nx maupun Turborepo memiliki solusi remote caching bawaan (Nx Cloud untuk Nx, Turborepo Remote Caching). Selain itu, platform CI/CD seperti GitHub Actions juga memiliki mekanisme caching yang bisa dimanfaatkan untuk dependensi (misal node_modules).

# Contoh GitHub Actions untuk caching node_modules
- name: Cache Node Modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

Ini adalah contoh dasar. Dengan Nx atau Turborepo, caching diterapkan pada level output tugas, jauh lebih granular dan efektif.

5. Paralelisasi dan Distribusi Tugas

Bahkan dengan selective builds dan caching, ada kalanya Anda masih memiliki banyak tugas yang harus dijalankan. Di sinilah paralelisasi dan distribusi tugas berperan.

5.1. Paralelisasi: Menjalankan Tugas Bersamaan

Jika ada beberapa proyek yang terpengaruh, dan mereka tidak memiliki ketergantungan satu sama lain, Anda bisa menjalankan build atau test mereka secara paralel. Ini memanfaatkan core CPU yang tersedia di runner CI/CD Anda.

Contoh dengan Nx:

# Nx secara default akan mencoba memparalelkan tugas sebisa mungkin
nx affected --target=test --parallel=3 # Jalankan hingga 3 tugas test secara paralel

5.2. Distribusi Tugas: Membagi Beban ke Banyak Mesin

Untuk monorepo yang sangat besar, satu runner CI/CD mungkin tidak cukup, bahkan dengan paralelisasi. Anda bisa mendistribusikan tugas ke beberapa runner atau mesin berbeda.

Analogi: Jika ada banyak mobil yang harus dicat, Anda tidak akan menyuruh satu orang mengecat semuanya sendirian, tapi membagi tugas itu ke beberapa orang atau bahkan beberapa bengkel berbeda yang bekerja secara simultan.

Tooling seperti Nx Cloud menyediakan fitur Distributed Task Execution (DTE) yang memungkinkan Anda mendistribusikan eksekusi tugas ke beberapa agent CI/CD. Ini sangat efektif untuk mengurangi waktu build dan test di lingkungan skala besar.

Penting: Pastikan runner CI/CD Anda memiliki spesifikasi yang cukup dan dapat di-scale secara horizontal jika Anda menggunakan strategi distribusi ini.

6. Pipeline CI/CD yang Adaptif dan Observabel

Untuk memaksimalkan efisiensi dan pengalaman developer, pipeline CI/CD Anda harus adaptif dan mudah dipantau.

6.1. Menggunakan Dynamic Pipelines

Alih-alih memiliki file konfigurasi CI/CD statis yang mencoba menangani semua skenario, Anda bisa membuat pipeline yang dinamis. Artinya, konfigurasi pipeline itu sendiri dihasilkan secara programatis berdasarkan perubahan yang terdeteksi.

Misalnya, di GitHub Actions, Anda bisa memiliki satu workflow utama yang menggunakan script untuk mendeteksi proyek yang terpengaruh (nx affected:graph --json) dan kemudian secara dinamis memanggil workflow lain atau menjalankan langkah-langkah yang sesuai.

# Contoh pseudo-code untuk dynamic pipeline di GitHub Actions
name: Monorepo CI
on: [push, pull_request]
jobs:
  run-affected-jobs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0 # Penting untuk git diff
      - name: Install dependencies
        run: npm ci
      - name: Determine affected projects
        id: affected
        run: |
          AFFECTED_APPS=$(nx print-affected --target=build --base=${{ github.base_ref }} --head=${{ github.head_ref }} --plain --type=app)
          echo "affected_apps=$AFFECTED_APPS" >> $GITHUB_OUTPUT
      - name: Build affected apps
        if: steps.affected.outputs.affected_apps != ''
        run: |
          for app in ${{ steps.affected.outputs.affected_apps }}; do
            nx build $app
          done
      # ... langkah-langkah lain yang dinamis

6.2. Integrasi dengan Developer Workflow

CI/CD yang efisien tidak hanya di server, tetapi juga di mesin developer. Pastikan tooling monorepo yang Anda gunakan juga memberikan pengalaman yang cepat secara lokal.

Pre-commit Hooks: Gunakan hook Git untuk menjalankan linting atau format kode hanya pada file yang berubah sebelum commit. Ini mencegah masalah masuk ke repositori.
Local Caching: Pastikan cache juga berfungsi dengan baik secara lokal, sehingga developer tidak perlu menunggu lama saat beralih antara tugas atau branch.

6.3. Observability Pipeline 🎯

Pantau kinerja pipeline CI/CD Anda. Alat seperti Nx Cloud tidak hanya menyediakan remote caching, tetapi juga visualisasi dan analitik tentang bagaimana pipeline Anda berjalan, di mana bottleneck-nya, dan berapa banyak waktu yang dihemat oleh caching. Ini membantu Anda terus mengoptimalkan pipeline.

Kesimpulan

Membangun CI/CD yang efisien di lingkungan monorepo memang memiliki tantangannya sendiri, tetapi dengan strategi yang tepat, hal ini sepenuhnya bisa diatasi. Kunci utamanya adalah membuat pipeline Anda “sadar monorepo” melalui:

Selective Builds & Testing: Hanya proses proyek yang terpengaruh perubahan dan dependensinya.
Caching Output: Simpan dan gunakan kembali hasil build/test sebelumnya, terutama dengan remote caching.
Paralelisasi & Distribusi Tugas: Manfaatkan semua sumber daya yang tersedia, baik di satu runner maupun di banyak runner.
Pipeline Adaptif & Observabel: Desain pipeline yang dinamis dan pantau performanya untuk terus melakukan optimasi.

Dengan mengadopsi strategi ini dan memanfaatkan monorepo management tools seperti Nx atau Turborepo, Anda tidak hanya akan mempercepat pipeline CI/CD, tetapi juga meningkatkan developer experience dan mengurangi biaya infrastruktur. Jadi, jangan takut dengan monorepo, rangkul potensinya dengan CI/CD yang cerdas!