Skip to content

Roadmap Migrasi

Roadmap bertahap untuk memodernisasi backend ATE secara aman, mengikuti pendekatan incremental / strangler-fig. Urutan fase dirancang agar setiap langkah meningkatkan keamanan langkah berikutnya.

Fase 0 — Stabilisasi & Fondasi

Tujuan: amankan sistem & buat jaring pengaman sebelum mengubah apa pun.

ItemAksiReferensi
Inventaris cronDokumentasikan crontab production aktual ke dalam repo (mis. file crontab.example)Background Jobs
Secret managementPindahkan secret ke vault/secret manager; rotasi kredensial yang pernah ter-commitKnown Issues #3
Amankan route ZimbraTambahkan auth/IP allowlist pada /api/v1/zimbras/*Known Issues #2
ObservabilityTambah structured logging, error tracking (mis. Sentry), metrics, alerting untuk job & callback
Characterization testsTulis test untuk alur kritikal: login, checkout, callback Xendit, reset kuota, parsing logtest/
CI gateTambah test + lint ke GitHub Actions sebelum deploy; tambah langkah migrasi terkontrol.github/workflows/
Snapshot skemapg_dump --schema-only production sebagai sumber kebenaran skemaMigrasi Sequelize
Backup otomatisPastikan backup DB terjadwal & teruji restore

Jangan lewati Fase 0

Tanpa observability dan test, semua perubahan di fase berikutnya menjadi berisiko tinggi pada sistem production.

Fase 1 — Modernisasi Internal (in-place)

Tujuan: upgrade fondasi teknis tanpa mengubah perilaku eksternal.

ItemAksi
Upgrade Node LTSNaik dari Node 14 ke Node LTS terbaru (mis. 20/22). Uji kompatibilitas dependency, perbaiki breaking changes.
Audit & upgrade dependencynpm audit, naikkan versi (Express, Sequelize, dll.), hapus yang tak terpakai (bull, mysql2 bila benar tak dipakai).
Standardisasi error & responseSatukan ke satu helper response & satu mekanisme error handling.
Queue yang andalGanti DB-queue + child-process dengan BullMQ + Redis (atau queue terkelola), dengan retry, dead-letter, dan observability.
Scheduler properPindahkan jadwal cron ke scheduler yang versioned di repo (mis. node-cron worker terdedikasi atau BullMQ repeatable jobs), bukan crontab tak terlihat.
TypeScript bertahapAdopsi TypeScript per modul (mulai dari util/helper), aktifkan strict secara bertahap.
Bersihkan skemaSelesaikan drift model vs migrasi; deprecate tabel tak terpakai (TransEmailLogs, JobDetails) setelah konfirmasi.
ContainerisasiBungkus app dalam Docker untuk konsistensi environment dev → prod.

Fase 2 — Strangler Modul Baru

Tujuan: bangun kapabilitas baru/terisolasi di stack terbaru, di belakang gateway.

ItemAksi
API gateway/routerTempatkan reverse proxy/gateway di depan monolith untuk merutekan per-endpoint.
Pilih modul kandidatMulai dari modul dengan coupling rendah & nilai tinggi (mis. reporting/observability atau service relay/pengiriman).
Implementasi modul baruBangun service baru (stack terbaru) memakai dokumentasi ini sebagai spesifikasi; pakai DB/skema yang sama atau kontrak API yang jelas.
Pindahkan trafik bertahapCanary/percentage rollout per endpoint, dengan kemampuan rollback cepat.
Idempotensi webhookSaat memindahkan callback (Xendit/SparkPost), pastikan pemrosesan idempoten.

Fase 3 — Konsolidasi & Cleanup

Tujuan: pensiunkan bagian lama, rapikan, dan dokumentasikan ulang.

ItemAksi
Pensiunkan kode lamaHapus modul monolith yang sudah di-strangle.
Hapus dead codeBersihkan blok comment, controller/route tak terpakai, typo folder (biliings).
Dokumentasi finalPerbarui situs dokumentasi ini agar mencerminkan arsitektur baru.
Hardening keamananReview menyeluruh auth (masa berlaku token, RBAC), rate limiting, input validation.

Urutan prioritas singkat

  1. Sekarang juga (Fase 0): observability, backup, amankan route Zimbra & secret, inventaris cron.
  2. Berikutnya (Fase 1): Node LTS + dependency, queue andal, scheduler versioned.
  3. Menengah (Fase 2): strangler untuk 1 modul percontohan.
  4. Akhir (Fase 3): konsolidasi & cleanup.

Target stack (usulan)

KomponenSekarangTarget usulan
RuntimeNode 14Node LTS (20/22)
BahasaJavaScriptTypeScript
QueueDB Jobs + child processBullMQ + Redis
SchedulerCrontab VPSScheduler versioned (repo)
DeploySSH + PM2 (VPS)Container (Docker) + orkestrasi/CI yang punya test gate
ORMSequelize 6Sequelize terbaru / Prisma (evaluasi)
ObservabilityWinston + log fileStructured logging + error tracking + metrics

Catatan

Pemilihan ORM target (tetap Sequelize vs pindah Prisma) sebaiknya diputuskan setelah Fase 0–1 berdasarkan kebutuhan tim dan kompleksitas query yang ada. Evaluasi terpisah disarankan sebelum komit.