Monorepo vs Multirepo #

Salah satu keputusan pertama yang perlu dibuat saat mengorganisasi konfigurasi Terraform di skala tim adalah: taruh semua di satu repository, atau pisahkan ke beberapa repository? Tidak ada jawaban universal yang berlaku untuk semua konteks. Monorepo mempermudah visibilitas dan refactoring lintas konfigurasi; multirepo memberikan isolasi dan ownership yang lebih jelas. Pilihannya bergantung pada ukuran tim, arsitektur infrastruktur, dan bagaimana kamu ingin mengelola dependency antar komponen.

Monorepo: Semua di Satu Tempat #

STRUKTUR MONOREPO TIPIKAL:

infra-repo/
  ├── modules/                  ← Shared modules
  │   ├── networking/
  │   ├── compute/
  │   └── database/
  │
  ├── environments/
  │   ├── dev/
  │   │   ├── networking/
  │   │   ├── compute/
  │   │   └── database/
  │   ├── staging/
  │   │   └── ...
  │   └── production/
  │       └── ...
  │
  ├── .github/workflows/        ← Satu CI/CD pipeline
  ├── .gitignore
  └── README.md

Semua infrastruktur ada di satu repository, dikelola bersama.

KEUNTUNGAN MONOREPO:

  ✓ Visibilitas penuh — semua perubahan terlihat di satu tempat
  ✓ Refactoring lebih mudah — ubah module, sekaligus update semua pemanggilnya
  ✓ Dependency antar konfigurasi lebih mudah dilacak
  ✓ Satu CI/CD pipeline untuk semua
  ✓ Lebih mudah untuk tim kecil yang mengelola semua infrastruktur
  ✓ Tidak ada versioning complexity antar module dan pemanggilnya

KELEMAHAN MONOREPO:

  ✗ Repository bisa jadi besar dan lambat seiring waktu
  ✗ Satu commit bisa mempengaruhi CI/CD untuk semua komponen
  ✗ Akses kontrol lebih sulit (sulit restrict tim tertentu ke folder tertentu)
  ✗ Perubahan modul yang tidak hati-hati bisa breaking semua pemanggilnya
  ✗ Coupling yang lebih ketat antar tim

Multirepo: Satu Repository per Komponen #

STRUKTUR MULTIREPO TIPIKAL:

  infra-networking-repo/
    ├── modules/vpc/
    ├── environments/dev/
    ├── environments/staging/
    └── environments/production/

  infra-compute-repo/
    ├── modules/ec2/
    ├── modules/asg/
    └── environments/...

  infra-database-repo/
    ├── modules/rds/
    └── environments/...

  infra-modules-repo/           ← Shared modules di repo terpisah
    ├── networking/
    ├── compute/
    └── database/
    # Versi: v1.0.0, v1.1.0, v2.0.0

  Setiap tim punya repository sendiri dengan akses dan pipeline terpisah.

KEUNTUNGAN MULTIREPO:

  ✓ Isolasi yang jelas — perubahan di satu repo tidak mempengaruhi yang lain
  ✓ Akses kontrol per-repository — tim database tidak bisa modifikasi networking
  ✓ Pipeline CI/CD lebih spesifik dan lebih cepat
  ✓ Module bisa punya versioning sendiri (v1.0, v1.1, v2.0)
  ✓ Tim bisa bergerak lebih independen

KELEMAHAN MULTIREPO:

  ✗ Visibilitas berkurang — sulit melihat gambaran besar infrastruktur
  ✗ Dependency management kompleks — harus kelola versi module antar repo
  ✗ Refactoring lintas repo lebih sulit dan perlu koordinasi
  ✗ Duplikasi pattern/konvensi jika tidak ada shared guidelines
  ✗ Overhead management lebih banyak (banyak repo, banyak pipeline)

Memilih Berdasarkan Konteks #

PILIH MONOREPO JIKA:

  Tim kecil (< 5 engineer):
    Overhead multirepo tidak sebanding, semua orang sudah tahu semua
    infrastruktur, monorepo memberikan visibilitas yang dibutuhkan

  Infrastruktur yang saling terkait erat:
    Networking, compute, dan database sering berubah bersama
    Refactoring lintas komponen sering terjadi

  Baru mulai dengan Terraform:
    Mulai sederhana, pecah menjadi multirepo nanti jika perlu
    "Premature separation" lebih berbahaya dari monorepo yang tumbuh besar

  Satu tim yang mengelola semua infrastruktur:
    Tidak ada kebutuhan isolasi antar tim

PILIH MULTIREPO JIKA:

  Tim besar dengan ownership yang jelas:
    Tim A hanya touch networking, Tim B hanya touch database
    Isolasi akses penting untuk governance

  Module yang dipakai banyak tim:
    Module perlu punya versi sendiri agar bisa di-upgrade secara bertahap
    Breaking change di module tidak langsung mempengaruhi semua pemanggilnya

  Compliance requirement:
    Audit harus terpisah per domain (network audit, data audit)
    Akses ke production database config tidak boleh ada di repo yang sama
    dengan compute

  Infrastruktur yang sudah mature dan stabil:
    Komponen sudah jarang refactoring lintas domain
    Pemisahan sudah natural sesuai ownership tim

Hybrid: Monorepo per Domain #

Pendekatan yang sering dipakai oleh tim menengah ke besar adalah monorepo per domain — satu repo untuk networking, satu repo untuk platform, satu repo untuk aplikasi, dan satu repo khusus untuk shared modules.

HYBRID STRUCTURE:

  infra-foundation-repo/        ← Tim Platform / Infrastructure
    ├── networking/
    ├── security/
    └── shared-services/

  infra-platform-repo/          ← Tim Platform Engineering
    ├── kubernetes/
    ├── observability/
    └── cicd-infrastructure/

  infra-app-repo/               ← Tim Application
    ├── environments/dev/
    ├── environments/staging/
    └── environments/production/

  terraform-modules-repo/       ← Tim Platform — dipakai semua
    ├── vpc/
    ├── eks/
    ├── rds/
    └── CHANGELOG.md

Ini memberikan isolasi yang cukup tanpa fragmentasi berlebihan.

Praktik yang Berlaku di Kedua Pendekatan #

Ada beberapa praktik yang penting terlepas dari monorepo atau multirepo.

# 1. Satu sumber kebenaran untuk versi Terraform
# Gunakan .terraform-version atau required_version di semua konfigurasi
terraform {
  required_version = ">= 1.6, < 2.0"
}

# 2. Lock file selalu di-commit
# .terraform.lock.hcl harus ada di .gitignore EXCEPTION
# (exclude semua tapi include lock file)
# .gitignore:
# .terraform/
# !.terraform.lock.hcl  ← khusus ini di-include

# 3. CODEOWNERS untuk kontrol review
# .github/CODEOWNERS:
# /environments/production/  @infrastructure-team @senior-engineers
# /modules/                  @platform-team

# 4. Konvensi direktori yang konsisten
# Terlepas dari monorepo/multirepo, struktur internal harus seragam
# environments/
#   dev/        staging/        production/
# (bukan: dev/  stg/  prod/ — inkonsistensi membingungkan)

Ringkasan #

Tidak ada pilihan universally better — monorepo lebih baik untuk tim kecil dan infrastruktur yang saling terkait, multirepo lebih baik untuk tim besar dengan ownership yang jelas.
Mulai dengan monorepo jika baru mulai — lebih mudah dipecah nanti sesuai kebutuhan, tapi sulit menggabungkan multirepo yang sudah ada.
Multirepo membutuhkan module versioning — module di repo terpisah harus punya versioning eksplisit agar pemanggilnya bisa upgrade secara bertahap.
Hybrid per-domain adalah sweet spot untuk tim menengah — satu repo per domain (networking, platform, app) dengan satu repo terpisah untuk shared modules.
CODEOWNERS di GitHub/GitLab membantu enforce siapa yang harus review perubahan di direktori tertentu — penting untuk monorepo yang dikelola banyak tim.
.terraform.lock.hcl harus di-commit di kedua pendekatan — memastikan semua orang dan pipeline menggunakan versi provider yang persis sama.

← Sebelumnya: Common Security Mistake Berikutnya: Lifecycle Management →