Software yang sudah lulus uji belum berguna sampai dipakai pengguna. Tahap penerapan (deployment) adalah merilis software ke lingkungan produksi agar dapat digunakan oleh pengguna akhir.

Tiga Lingkungan

Software biasanya berpindah melewati tiga lingkungan:

Mengapa perlu staging? Karena laptop developer berbeda dengan server sungguhan. Versi database bisa berbeda, data bisa jauh lebih banyak, dan pengaturan keamanan bisa lebih ketat. Staging dibuat semirip mungkin dengan produksi, sehingga masalah yang hanya muncul di "dunia nyata" bisa ketahuan sebelum menyentuh pengguna.

Pada aplikasi kas kelas, development adalah laptopmu, staging adalah salinan aplikasi yang dicoba bendahara dengan data contoh, dan production adalah aplikasi yang dipakai seluruh kelas.

Empat Strategi Rilis

Cara merilis juga perlu dipilih. Deck menyebut empat strategi:

Mari pahami dengan analogi kantin sekolah yang mengganti menu.

• Big Bang: besok semua menu lama diganti total. Kalau menu baru tidak laku, seluruh kantin rugi.
• Rolling: satu per satu kios mengganti menu, sampai semua kios memakai menu baru.
• Blue-Green: kantin punya dua dapur identik. Dapur biru masih menyajikan menu lama, dapur hijau sudah siap menu baru. Pembeli dialihkan ke dapur hijau. Kalau ada masalah, pembeli langsung dikembalikan ke dapur biru.
• Canary: menu baru ditawarkan dulu ke satu kelas. Kalau responsnya baik, diperluas ke seluruh sekolah.

Nama "canary" berasal dari burung kenari yang dulu dibawa penambang sebagai tanda bahaya awal. Sekelompok kecil pengguna berperan sebagai tanda awal bahwa rilis aman atau tidak.

Selalu Siapkan Rollback

Apa pun strateginya, selalu siapkan rencana rollback, yaitu cara kembali ke versi sebelumnya kalau rilis bermasalah. Strategi Blue-Green dan Canary mengurangi risiko saat rilis karena rollback-nya mudah atau dampaknya kecil.

Logika canary bisa dimodelkan dalam kode. Rilis naik bertahap selama tingkat error masih di bawah batas, dan berhenti kalau melewatinya:

function evaluasiCanary(tahapPersen, errorPerTahap, batasError) {
  for (let i = 0; i < tahapPersen.length; i++) {
    if (errorPerTahap[i] > batasError) {
      return { status: "rollback", berhentiDi: tahapPersen[i] };
    }
  }
  return { status: "rilis penuh", berhentiDi: 100 };
}

console.log(evaluasiCanary([5, 25, 50], [0.1, 0.2, 3.0], 1));
// { status: "rollback", berhentiDi: 50 }

Kamu akan menulis versi ini sendiri di latihan bab ini.

Output Penerapan

Deliverable tahap ini: Release Notes, Panduan Instalasi, Manual Pengguna, dan materi pelatihan. Untuk kas kelas, release notes bisa berupa pesan singkat di grup kelas: "Versi 1.1: sekarang bisa melihat riwayat pembayaranmu sendiri."

Software terus dirawat setelah rilis. Tahap ini umumnya berlangsung paling lama sepanjang usia sistem. Aplikasi kas kelas mungkin dibangun dalam 6 minggu, tetapi dipakai dan dirawat selama bertahun-tahun.

Empat Jenis Pemeliharaan

Cara mudah mengingatnya:

• Korektif = memperbaiki yang rusak.
• Adaptif = menyesuaikan dengan dunia luar yang berubah.
• Perfektif = membuat lebih baik sesuai keinginan pengguna.
• Preventif = mencegah masalah sebelum terjadi.

Bedakan adaptif dan perfektif dengan bertanya: perubahan ini dipicu dunia luar (sistem operasi, aturan, platform) atau dipicu keinginan pengguna? Kalau dunia luar, adaptif. Kalau keinginan pengguna, perfektif.

Pemeliharaan Menyerap Biaya Besar

Pemeliharaan sering menyerap porsi biaya terbesar dalam total umur software. Karena itu desain yang mudah dirawat sangat penting. Keputusan di tahap desain, seperti memisahkan modul dengan rapi, terasa manfaatnya bertahun-tahun kemudian saat ada perubahan.

Kembali ke Perencanaan

Permintaan perubahan besar memicu siklus SDLC baru. Misalnya wali kelas meminta aplikasi kas dipakai untuk seluruh angkatan, bukan satu kelas saja. Ini bukan sekadar perbaikan kecil. Perlu perencanaan ulang, analisis kebutuhan baru, desain ulang database, dan seterusnya. Itulah mengapa SDLC disebut siklus: tahap ketujuh membawa kita kembali ke tahap pertama.

• Merilis tanpa rencana rollback. Saat ada masalah, tim panik karena tidak tahu cara kembali ke versi lama.
• Melewatkan staging. Masalah yang hanya muncul di lingkungan mirip produksi baru ketahuan setelah pengguna terdampak.
• Memakai Big Bang untuk sistem besar tanpa alasan kuat. Semua pengguna langsung terkena kalau ada masalah.
• Menganggap pemeliharaan sebagai pekerjaan kecil. Justru tahap ini paling lama dan sering paling mahal.