3-4 · Bab 3 · 4 menit baca

Deployment: Tindakan Aktif Menempatkan Artifact ke Lingkungan

Pelajari perbedaan mendasar antara deployment dan release, mengapa deployment adalah tindakan aktif yang dapat diulang, dibalikkan, dan diverifikasi, serta praktik terbaik untuk tim DevOps dan SRE.

Deployment: Tindakan Aktif Menempatkan Artifact ke Lingkungan

Anda sudah membangun aplikasi, mengemasnya menjadi artifact, dan menyimpannya di repositori. Lalu apa? Artifact yang duduk di repositori hanyalah sebuah file. Ia baru berguna ketika ditempatkan ke dalam lingkungan dan benar-benar berjalan. Tindakan menempatkan dan menjalankan inilah yang oleh para insinyur disebut sebagai deployment.

Deployment bukanlah kondisi pasif. Ini adalah tindakan aktif. Sebelum deployment, lingkungan staging Anda menjalankan versi 1.1.0. Setelah deployment, ia menjalankan versi 1.2.0. Ada yang berubah di lingkungan tersebut. Seseorang atau sesuatu mengambil artifact, memindahkannya ke server yang tepat, dan menjalankannya.

Apa yang Sebenarnya Terjadi Saat Deployment

Ketika sebuah tim memutuskan untuk mengirim versi 1.2.0 ke staging, serangkaian langkah konkret harus terjadi. Seseorang menarik artifact dari repositori. Mereka mentransfernya ke server staging. Mereka menghentikan proses lama, memulai proses baru, dan memverifikasi bahwa ia berjalan. Lingkungan sekarang memiliki status baru.

Berikut adalah contoh konkret dari langkah-langkah tersebut dalam bentuk perintah shell:

scp myapp-v1.2.0.jar user@staging-server:/opt/myapp/ && \
ssh user@staging-server "systemctl stop myapp && \
  cp /opt/myapp/myapp-v1.2.0.jar /opt/myapp/current.jar && \
  systemctl start myapp"

Inilah mengapa deployment berbeda dari sekadar menyimpan file. Anda bisa memiliki repositori artifact yang sempurna dengan setiap versi yang pernah dibuat, tetapi sampai artifact tersebut ditempatkan ke lingkungan dan dieksekusi, tidak ada yang terkirim. Deployment adalah jembatan antara "kami sudah membangunnya" dan "ia berjalan di suatu tempat."

Diagram urutan berikut mengilustrasikan pemisahan antara deployment dan release:

sequenceDiagram participant AR as Artifact Registry participant DT as Deployment Tool participant S as Server participant LB as Load Balancer DT->>AR: Tarik artifact v1.2.0 DT->>S: Transfer artifact DT->>S: Hentikan proses lama (v1.1.0) DT->>S: Mulai proses baru (v1.2.0) DT->>S: Verifikasi kesehatan S-->>DT: Sehat Note over DT,LB: Deployment selesai DT->>LB: Alihkan traffic ke v1.2.0 Note over DT,LB: Release terjadi

Pertanyaan yang muncul secara alami adalah: apakah deployment berarti pengguna bisa langsung menggunakan versi baru? Belum tentu. Deployment dan release adalah dua konsep yang berbeda, meskipun tim sering melakukannya bersamaan.

Deployment Versus Release

Deployment adalah tindakan teknis. Anda menempatkan artifact ke lingkungan dan menjalankannya. Release adalah tentang akses. Ia menjawab pertanyaan: kapan pengguna benar-benar mulai menggunakan versi baru?

Bayangkan tim Anda melakukan deployment versi 1.2.0 ke production pada pukul 2:00 pagi. Server production sekarang menjalankan versi baru, tetapi tim sengaja tidak mengarahkan traffic pengguna ke sana. Deployment sudah terjadi. Release belum. Pengguna masih menggunakan versi lama. Tim dapat memverifikasi bahwa versi baru sehat sebelum membuka pintu.

Sekarang bayangkan skenario sebaliknya. Tim melakukan deployment ke production dan segera mengarahkan semua pengguna ke versi baru. Dalam kasus ini, deployment dan release terjadi dalam langkah yang sama. Keduanya adalah pendekatan yang valid, tetapi memahami perbedaannya memberi Anda pilihan.

Mengapa pemisahan ini penting? Karena deployment bisa gagal. Ketika itu terjadi, Anda perlu tahu cara mengembalikan lingkungan ke status sebelumnya. Tindakan itu disebut rollback. Rollback pada dasarnya adalah deployment versi lama ke lingkungan yang sama. Jika tim Anda hanya tahu cara "mendorong versi baru" tanpa memahami bahwa deployment adalah tindakan yang dapat dibalikkan, Anda akan kesulitan ketika terjadi masalah.

Deployment Tidak Selalu Mulus

Bahkan dengan perencanaan yang matang, deployment bisa menemui masalah. Server mungkin kehabisan ruang disk. File konfigurasi mungkin memiliki typo. Artifact yang diunduh dari repositori bisa rusak. Masalah jaringan bisa menyebabkan timeout selama transfer.

Inilah mengapa setiap deployment memerlukan verifikasi. Setelah artifact ditempatkan dan berjalan, seseorang atau sesuatu harus memeriksa bahwa lingkungan benar-benar sehat. Apakah aplikasi merespons permintaan? Apakah log bersih? Apakah metrik yang diharapkan berada dalam kisaran normal?

Verifikasi bisa dilakukan secara otomatis atau manual, tetapi harus ada. Deployment yang selesai tanpa verifikasi hanyalah berharap tidak ada yang salah. Harapan bukanlah strategi deployment.

Implikasi Praktis

Begitu Anda melihat deployment sebagai tindakan aktif, bukan kondisi pasif, beberapa hal menjadi lebih jelas.

Pertama, deployment dapat diulang. Jika Anda bisa melakukan deployment versi 1.2.0 hari ini, Anda seharusnya bisa melakukan deployment versi 1.2.0 lagi besok, ke lingkungan yang sama, dengan hasil yang sama. Jika tidak demikian, proses deployment Anda memiliki langkah atau dependensi tersembunyi.

Kedua, deployment dapat dibalikkan. Jika versi 1.2.0 menyebabkan masalah, Anda seharusnya bisa melakukan deployment versi 1.1.0 kembali ke lingkungan yang sama. Itulah rollback. Jika rollback terasa menyakitkan atau berisiko, proses deployment Anda perlu perbaikan.

Ketiga, deployment dapat diverifikasi. Anda harus tahu, dalam waktu yang wajar, apakah deployment berhasil atau gagal. Bukan hanya apakah skrip berjalan tanpa error, tetapi apakah aplikasi benar-benar bekerja dengan benar di lingkungan tersebut.

Daftar Periksa Deployment Sederhana

Sebelum Anda menyatakan deployment selesai, lakukan pemeriksaan berikut:

Apakah artifact ditempatkan ke lingkungan yang benar?
Apakah versi baru benar-benar berjalan dan menerima traffic?
Apakah pengecekan kesehatan dasar lolos (kode respons, latensi, tingkat error)?
Dapatkah Anda memastikan versi lama sudah tidak berjalan (kecuali Anda melakukan peluncuran bertahap)?
Apakah Anda tahu cara melakukan rollback jika diperlukan, dan apakah jalur rollback tersebut sudah diuji?

Daftar periksa ini tidak lengkap, tetapi mencakup minimum. Setiap tim harus memperluasnya berdasarkan karakteristik lingkungan dan aplikasi mereka sendiri.

Kesimpulan

Deployment adalah momen ketika artifact Anda berhenti menjadi file dan mulai menjadi layanan yang berjalan. Ini adalah tindakan aktif, dapat diulang, dapat dibalikkan, dan dapat diverifikasi. Memisahkan deployment dari release memberi Anda kendali atas kapan pengguna melihat perubahan. Memverifikasi setiap deployment mencegah Anda menemukan masalah setelah pengguna Anda menemukannya.

Lain kali ketika tim Anda berkata "kami sudah deploy," tanyakan: apakah kita benar-benar menempatkan artifact dan memverifikasi bahwa ia berjalan? Atau kita hanya menekan tombol dan berharap? Jawabannya akan memberi tahu Anda seberapa matang proses deployment Anda sebenarnya.