Roadmap Implementasi

Living checklist

Halaman ini akan dicentang bertahap seiring pengembangan berjalan — bukan rencana yang dikunci di awal. Urutan bisa berubah tergantung jawaban dari poin #0.

0. Pertanyaan Pembuka (perlu dijawab sebelum langkah teknis dimulai)

  • [ ] Aplikasi dibangun dari nol, atau adaptasi dari sistem yang sudah ada (mis. sispada atau SIA UMS existing lain)? Ini menentukan apakah langkah berikutnya adalah "desain skema baru" atau "audit skema existing untuk ditambah tenant_id + RLS".
  • [x] Stack teknologi: Django (Python) — lihat Keputusan Arsitektur §4
  • [x] Modul awal: draft cakupan modul sudah diberikan Admin & dievaluasi — lihat Cakupan Modul. Masih ada 5 pertanyaan terbuka di dalamnya (jalur PMB, prasyarat mata kuliah, skema UKT, rekonsiliasi pembayaran, BKD) sebelum desain skema data final.
  • [x] Tema admin UI: pakai Django admin default dulu (label disesuaikan), keputusan visual final ditunda — lihat Keputusan Arsitektur §4.1

1. Fondasi Data (Database)

  • [x] Desain skema tabel Tenant (identitas kampus, domain custom bila ada, status aktif) — lihat Skema Data — Fondasi
  • [x] Desain tabel Struktur Organisasi, Kalender Akademik, Kurikulum, Jabatan Struktural & Riwayat Jabatan, RBAC (Modul 0 & Modul 9) — dikerjakan bertahap, fondasi dulu
  • [x] Tulis kebijakan Row-Level Security contoh (CREATE POLICY ... USING (tenant_id = current_setting('app.tenant_id')))
  • pola middleware Django (SET LOCAL dibungkus atomic()) — lihat Skema Data — Fondasi §10
  • [x] Desain skema Akademik Inti (Mahasiswa, Registrasi Ulang, Kelas Mata Kuliah, KRS, Nilai, Presensi, Cuti Akademik, Surat-Menyurat, Peringatan Akademik, Tugas Akhir/Skripsi) — lihat Skema Data — Akademik Inti
  • [x] Desain skema Keuangan (KelompokUKT, TarifUKT, TagihanUKT, JenisBiayaFlat, TagihanBiayaFlat, Pembayaran, SlipGaji) — lihat Skema Data — Keuangan
  • [x] Desain skema HRD (Pegawai diperluas, EvaluasiKinerja, Cuti Pegawai, Program Pelatihan, BKD, rincian gaji) — lihat Skema Data — HRD
  • [x] Desain skema Biro Aset (Master Aset, Mutasi, Pemeliharaan, Penyusutan, Penghapusan, Opname) — lihat Skema Data — Biro Aset
  • [x] Desain skema Perpustakaan (KategoriBuku, Buku, PeminjamanBuku, DendaKeterlambatan) — lihat Skema Data — Perpustakaan. Seluruh 7 modul fungsional sudah punya skema data.
  • [x] Uji isolasi: dua tenant dummy diuji nyata di postgres-cluster (bukan simulasi, 7 skenario) — lihat Skema Data — Fondasi §11. 3 temuan penting ditemukan & diperbaiki: (1) kebijakan RLS wajib pakai current_setting(..., true) — bentuk satu-argumen crash bila konteks tenant lupa di-set; (2) superuser (postgres) selalu bypass RLS — tidak pernah dipakai untuk koneksi aplikasi; (3) FORCE ROW LEVEL SECURITY wajib di setiap tabel supaya owner tabel (appuser) ikut tunduk RLS — dengan ini, appdb/appuser yang sudah ada bisa dipakai langsung, tidak perlu database/role baru. §1 Fondasi Data selesai sepenuhnya.

2. Fondasi Infrastruktur (K8s)

Selesai — lihat Fondasi Infrastruktur K8s (Skeleton)

  • [x] Namespace sia-multitenant dibuat — terpisah dari demo-app/galera-system/ postgres-system yang sudah ada
  • [x] Database: pakai appdb/appuser yang sudah ada di postgres-cluster (kosong, belum dipakai apa pun) — tidak perlu database/role baru, asal FORCE ROW LEVEL SECURITY diterapkan di setiap tabel (lihat Skema Data — Fondasi §11)
  • [x] Deployment skeleton Django + Service + health check (/sia/healthz/, benar-benar menguji konektivitas appdb) — live, migrasi bawaan Django berhasil ke appdb
  • [x] IngressRoute — dipakai path /sia/ di oneke.ums.id (bukan subdomain terpisah), keputusan sadar demi kecepatan tahap skeleton — lihat Fondasi Infrastruktur K8s §5
  • [x] Label Django admin disesuaikan (site_header, site_title, index_title) — ditemukan Django sudah punya terjemahan Indonesia bawaan untuk seluruh label lain (lihat Fondasi Infrastruktur K8s §6)

3. Custom Domain per Tenant

  • [ ] Buat runbook onboarding tenant baru (langkah manual: CNAME → IngressRoute → cert-manager → mapping domain-tenant di database) — lihat Keputusan Arsitektur §2
  • [ ] Uji end-to-end dengan satu domain contoh (mis. domain uji milik tim, bukan domain kampus sungguhan) sebelum onboarding kampus pertama

4. Operasional

  • [ ] Tambahkan monitoring khusus SIA ke Grafana/Prometheus yang sudah ada (mis. jumlah tenant aktif, request per tenant) — reuse Instalasi Monitoring
  • [ ] Tambahkan status SIA multi-tenant ke widget monitor homepage (lihat Monitor Custom di Homepage) bila sudah live
  • [ ] Backup: pastikan data SIA tercakup di backup S3 yang sudah ada untuk postgres-cluster, atau butuh kebijakan retensi terpisah per tenant

Kembali ke Ringkasan & Visi atau Keputusan Arsitektur.