Deployment Checklist

Hari peluncuran bukan saat menemukan bahwa kata sandi masih tertanam di kode atau index utama belum dibuat. Kesalahan kecil yang luput sebelum go-live berubah menjadi insiden besar sesudahnya, ketika pengguna nyata sudah mengetuk pintu. Chapter ini merangkum seluruh persiapan Section ini menjadi satu daftar periksa yang bisa dijalankan berurutan, lengkap dengan cara memverifikasi tiap butirnya — sebagian langsung dari dalam mongosh.

Tabel Periksa Go-Live #

Urutan tabel sengaja mengikuti urutan ketergantungan: keamanan dan konektivitas (1–4) lebih dulu, ketahanan (5–6), lalu kesiapan data dan aplikasi (7–11), ditutup dokumentasi (12).

Memverifikasi Hak Akses Koneksi #

Butir paling penting dari daftar keamanan adalah memastikan koneksi aplikasi tidak membawa hak yang berlebihan. Perintah connectionStatus melaporkan identitas dan seluruh hak koneksi yang sedang berjalan:

printjson(db.runCommand({ connectionStatus: 1, showPrivileges: true }).authInfo)

Output yang Dihasilkan:

{
  authenticatedUsers: [],
  authenticatedUserRoles: [],
  authenticatedUserPrivileges: []
}

Pada server latihan kita ketiga daftar itu kosong karena autentikasi memang tidak diaktifkan. Pada cluster Atlas, authenticatedUsers berisi nama user (misalnya app-tokobuku), authenticatedUserRoles berisi role beserta cakupannya, dan authenticatedUserPrivileges merinci aksinya. Saat meninjaunya, bandingkan dengan kebutuhan aplikasi: bila aplikasi hanya membaca-menulis collection tokobuku, role readWrite@tokobuku pada app-tokobuku adalah jawaban yang benar — lebih luas dari itu berarti kembali ke Chapter Database Access.

Memverifikasi Index dan Validator #

Dua butir data bisa diverifikasi dalam satu sesi singkat. Kita siapkan collection uji menyerupai kondisi produksi:

use latihan_golive

Output yang Dihasilkan:

switched to db latihan_golive

db.pesanan.insertOne({ pelanggan: "[email protected]", total: 150000, status: "baru" })

Output yang Dihasilkan:

{
  acknowledged: true,
  insertedId: ObjectId('6ad3fc1f9862e7b403b9d89f')
}

db.pesanan.createIndex({ pelanggan: 1 }, { name: "idx_pelanggan" })

Output yang Dihasilkan:

idx_pelanggan

printjson(db.pesanan.getIndexes().map(i => i.name))

Output yang Dihasilkan:

[
  '_id_',
  'idx_pelanggan'
]

Daftar nama index dari getIndexes() inilah yang dibandingkan dengan migration script — setiap index yang dipakai query utama harus hadir di sini sebelum go-live. Lanjut ke validator, kita pasang aturan $jsonSchema pada collection yang sama:

db.runCommand({ collMod: "pesanan", validator: { $jsonSchema: { required: [ "pelanggan", "total" ], properties: { total: { minimum: 0 } } } } })

Output yang Dihasilkan:

{
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1792277535, i: 2 }),
    signature: {
      hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
      keyId: Long('0')
    }
  },
  operationTime: Timestamp({ t: 1792277535, i: 2 })
}

Field ok: 1 menandakan aturan terpasang (sisanya metadata replikasi). Kita buktikan aturannya benar-benar tercatat pada definisi collection:

const info = db.getCollectionInfos({ name: "pesanan" })
printjson(info[0].options)

Output yang Dihasilkan:

{
  validator: {
    '$jsonSchema': {
      required: [
        'pelanggan',
        'total'
      ],
      properties: {
        total: {
          minimum: 0
        }
      }
    }
  },
  validationLevel: 'strict',
  validationAction: 'error'
}

Objek options menampilkan validator yang baru saja dipasang beserta dua kebijakan bawaannya: validationLevel: 'strict' menerapkan aturan pada seluruh document baru, dan validationAction: 'error' menolak tulisan yang melanggar. Kedua perilaku ini dibahas tuntas pada Section Schema Validation — pada hari go-live, cukup pastikan validator tiap collection inti muncul di hasil getCollectionInfos().

Backup yang Benar-benar Teruji #

Butir kelima sering dianggap selesai begitu tombol backup dinyalakan, padahal backup yang belum pernah dipulihkan hanyalah harapan.

Pada cluster Dedicated, panel Deployment → Backup menampilkan snapshot beserta jadwal dan masa simpannya; tombol restore menawarkan pemulihan ke cluster lain atau mengunduh berkas untuk mongorestore — teknik yang sama dengan yang kita pakai pada Chapter Environment Separation. Mekanisme backup dan pemulihan secara mendalam ada di Section Backup dan Recovery.

Rangkuman #

• Jalankan dua belas butir periksa secara berurutan: keamanan dan konektivitas, ketahanan, kesiapan data dan aplikasi, lalu runbook.
• connectionStatus membuktikan hak koneksi aktual; getIndexes() dan getCollectionInfos() membuktikan index serta validator terpasang — semuanya dari dalam mongosh.
• Backup hanya dianggap siap setelah satu kali restore uji berhasil dijalankan terhadap snapshot terbaru.
• Daftar ini melengkapi (bukan menggantikan) Chapter Security Checklist: butir keamanan di sana berlaku untuk server, di sini untuk peluncuran aplikasi.