Deployment (penerapan)

Bagaimana urutan proses deploy situs web?

Deploy biasanya berjalan dengan urutan ‘perbaiki → cek pratinjau → setujui → terapkan ke alamat asli → cek setelah rilis’. Layanan hosting yang banyak dipakai sekarang mengunggah perubahan lebih dulu ke alamat pratinjau, lalu menggantinya ke alamat asli setelah pengecekan selesai.

Perubahan yang sangat kecil seperti satu salah ketik kadang langsung di-deploy tanpa cek pratinjau. Namun bagian yang menyangkut janji kepada pelanggan seperti harga · reservasi · pembayaran lebih aman dilihat sekali di pratinjau sebelum diterapkan.

Lama deploy berbeda tergantung ukuran situs web dan cara hostingnya. Situs web kecil sering selesai dalam beberapa menit, tetapi ingat bahwa sebelum menerima pemberitahuan selesai, tampilannya mungkin belum berubah.

1. 01Anda meminta perubahan yang diinginkan.
2. 02Pembuat situs memperbaikinya lalu mengunggah ke alamat pratinjau.
3. 03Anda mengecek bagian yang berubah di pratinjau dan menyetujuinya.
4. 04Pembuat situs melakukan deploy ke alamat asli. Pada saat ini juga terjadi proses mengemas kode menjadi file untuk tampilan sungguhan (build).
5. 05Setelah deploy selesai, cek lagi bagian yang berubah serta tombol reservasi · pertanyaan di alamat asli.
6. 06Catat kapan dan apa yang diubah.

Apa bedanya deploy, hosting, dan domain?

Domain adalah alamat usaha, hosting adalah tempat file situs web diletakkan, dan deploy adalah tindakan mengunggah file baru ke tempat itu. Jika salah satu saja bermasalah, pelanggan tidak bisa melihat situs web dengan benar.

Saat berganti vendor atau pindah hosting, ketiganya bergerak bersamaan sehingga mudah membingungkan. Meski domain tetap dan hanya hosting yang pindah, setelah deploy ke hosting baru, koneksi domain harus diubah agar mengarah ke tempat baru supaya pelanggan melihat tampilan baru.

Jika perpanjangan domain terlewat, sebaik apa pun deploy-nya, alamat tidak akan terbuka. Cek juga kapan tanggal kedaluwarsa domain dan apakah perpanjangan otomatis aktif.

Sudah di-deploy, kenapa perubahannya belum terlihat?

Kebanyakan karena tampilan lama tersimpan (cache) di suatu tempat. Cache adalah fitur yang menyimpan sementara file yang sudah diterima agar tampilan yang sama bisa ditampilkan cepat, dan tepat setelah deploy hal ini bisa membuat tampilan lama masih terlihat.

Cache ada di browser ponsel pelanggan, dan juga di jaringan pengiriman (CDN) yang menaruh salinan di berbagai wilayah agar situs web terkirim cepat. Messenger seperti KakaoTalk juga menyimpan foto dan judul pratinjau tautan tersendiri, jadi meski foto utama diganti, pratinjau di messenger bisa tetap yang lama untuk sementara.

Saat mengecek, membuka lewat jendela penyamaran browser atau ponsel lain bisa mengurangi pengaruh cache. Deskripsi di hasil pencarian baru berubah setelah mesin pencari berkunjung lagi, jadi kadang butuh beberapa hari.

Bagaimana cara mengembalikan situs jika ada masalah setelah deploy?

Banyak layanan hosting menyimpan versi deploy sebelumnya, sehingga saat terjadi masalah, alamat dihubungkan lagi ke versi sebelumnya (rollback). Misalnya, Vercel memuat panduan fitur untuk langsung kembali ke deploy produksi sebelumnya.

Hanya saja, yang dikembalikan adalah tampilan dan kode. Data seperti reservasi · pesanan · pertanyaan yang ditinggalkan pelanggan di sela waktu itu disimpan terpisah sehingga tidak ikut kembali. Inilah alasan cadangan dibuat lebih dulu untuk deploy besar yang mengubah struktur data.

Karena itu, jika ada catatan deploy ‘kapan dan apa yang diubah’, saat terjadi masalah bisa cepat diketahui deploy mana penyebabnya dan kembali ke versi tepat sebelumnya.

Anda hampir tidak pernah perlu menekan tombol rollback sendiri, tetapi jika vendor sudah menjawab ‘jika ada masalah, bisa langsung dikembalikan ke tampilan sebelumnya’, Anda bisa menyerahkan deploy dengan jauh lebih tenang.

Kapan waktu terbaik untuk deploy?

Kiat umumnya adalah deploy saat pelanggan paling sedikit, pada hari ketika masalah bisa langsung ditangani. Deploy itu sendiri jarang membuat situs web berhenti, tetapi jika ada kesalahan di bagian yang berubah, pelanggan bisa menemukannya lebih dulu.

Untuk restoran, hindari tepat sebelum jam makan siang · makan malam; untuk salon, lebih baik diterapkan di waktu senggang hari kerja daripada pagi akhir pekan yang padat reservasi. Jika studio kerajinan berencana mengumumkan pendaftaran kelas baru, lebih aman deploy sehari sebelum pengumuman dan menuntaskan pengecekan.

Untuk konten yang harus berubah pada waktu tertentu seperti dimulainya acara atau diskon, sepakati jadwal dan penanggung jawab pengecekan dengan vendor lebih dulu.

Memantau sekitar 30 menit setelah deploy apakah notifikasi pertanyaan · reservasi masuk seperti biasa juga kebiasaan yang baik. Jika notifikasi tiba-tiba berhenti, segera beri tahu vendor agar bisa diputuskan perlu rollback atau tidak.

Apa yang perlu ditanyakan ke pembuat situs soal deploy?

Cara deploy berbeda di tiap vendor, jadi jika ditanyakan di awal, Anda tidak bingung setiap kali meminta perubahan.

Saat menerima pemberitahuan deploy selesai, buka sendiri bagian yang berubah sesuai pemberitahuan, lalu balas bahwa tidak ada masalah. Dengan begitu tersimpan catatan yang bisa dicek kedua pihak tentang kapan setiap perubahan selesai.

Untuk situs web dengan panel admin yang bisa diubah sendiri, tanyakan juga apakah perubahan langsung berlaku saat disimpan atau perlu deploy terpisah. Tergantung caranya, waktu perubahan muncul di layar pelanggan berbeda.

• Biasanya berapa lama dari permintaan perubahan sampai deploy
• Apakah ada kesempatan mengecek lewat pratinjau sebelum deploy
• Bagaimana pemberitahuan saat deploy selesai
• Apakah bisa kembali ke versi sebelumnya jika terjadi masalah
• Seberapa sering data reservasi · pesanan dicadangkan
• Apakah perubahan mendesak (kesalahan harga, dan lain-lain) bisa diterapkan di luar hari kerja