Apa yang Terjadi Setelah Pipeline Anda Selesai: Tindakan Pasca, Pembersihan, dan Bukti
Anda baru saja melihat pipeline Anda berubah menjadi hijau. Semua pengujian lolos, deployment berhasil, dan chat tim mendapat pesan singkat "selesai". Kebanyakan orang menutup tab dan beralih ke tugas berikutnya. Namun jika Anda berhenti di situ, Anda meninggalkan pipeline setengah jadi.
Sebuah pipeline belum lengkap hanya karena deployment berhasil. Ada tiga hal yang perlu terjadi setelah pengujian terakhir lolos, dan melewatkannya akan menimbulkan masalah yang baru muncul berminggu-minggu atau berbulan-bulan kemudian.
Notifikasi yang Benar-Benar Membantu
Hal pertama yang harus dilakukan pipeline saat selesai adalah memberi tahu seseorang. Namun tidak semua notifikasi berguna. Pesan yang hanya mengatakan "deploy berhasil" atau "build gagal" adalah kebisingan. Ini memaksa orang membuka log pipeline hanya untuk mencari tahu apa yang terjadi.
Notifikasi yang baik membawa konteks. Notifikasi harus mencakup:
- Perubahan apa yang diproses (commit hash atau ID merge request)
- Siapa yang memicu pipeline
- Lingkungan mana yang menerima deployment
- Apakah semuanya lolos atau ada yang gagal
- Tautan langsung ke pipeline run
Untuk tim kecil, pesan chat sudah cukup. Untuk organisasi yang lebih besar, Anda mungkin ingin mengirim notifikasi ke email, issue tracker, atau dashboard monitoring. Medianya tidak sepenting kontennya. Jika notifikasi Anda tidak membantu seseorang memutuskan apakah perlu bertindak, itu hanya gangguan lain.
Pikirkan tentang orang yang mendapat panggilan pada jam 2 pagi karena produksi bermasalah. Mereka perlu tahu segera: apakah ada deployment baru? Siapa yang melakukannya? Apa yang berubah? Notifikasi yang terstruktur dengan baik menjawab pertanyaan-pertanyaan itu sebelum siapa pun harus membuka browser.
Berikut adalah cuplikan YAML praktis untuk langkah notifikasi Slack yang menyertakan konteks penting:
notify-slack:
stage: post-deploy
image: curlimages/curl:latest
script:
- |
curl -X POST -H "Content-type: application/json" \
--data "{
\"text\": \"Deployment complete\",
\"blocks\": [
{
\"type\": \"section\",
\"text\": {
\"type\": \"mrkdwn\",
\"text\": \"*Pipeline finished*\nCommit: \`$CI_COMMIT_SHORT_SHA\`\nAuthor: $GITLAB_USER_LOGIN\nEnvironment: production\nStatus: $CI_JOB_STATUS\nLink: $CI_PIPELINE_URL\"
}
}
]
}" \
$SLACK_WEBHOOK_URL
only:
- main
Langkah ini hanya berjalan di branch utama, mengirimkan commit hash, penulis, lingkungan, dan tautan pipeline langsung, sehingga siapa pun yang menerimanya dapat langsung menilai situasi tanpa membuka log.
Membersihkan Sumber Daya Sementara
Setiap kali pipeline berjalan, ia menciptakan sumber daya sementara. Workspace di runner. Container yang dijalankan untuk pengujian. Volume penyimpanan sementara. Artifak build yang hanya diperlukan selama fase build. Dependensi yang diunduh.
Jika Anda tidak membersihkannya, semuanya akan menumpuk. Ruang disk penuh. Runner melambat. Dan lebih buruk lagi, sisa state dari satu pipeline dapat mengganggu proses berikutnya. Pengujian yang lolos secara lokal mungkin gagal di CI karena workspace masih memiliki file dari build sebelumnya.
Pembersihan harus otomatis. Jangan mengandalkan seseorang untuk mengingat menghapus sesuatu secara manual. Sebagian besar platform pipeline memiliki mekanisme pembersihan bawaan, tetapi Anda perlu memverifikasi bahwa mekanisme tersebut benar-benar berfungsi untuk pengaturan spesifik Anda. Container yang dibersihkan oleh platform mungkin masih meninggalkan volume yang ter-mount. Workspace yang dihapus mungkin masih memiliki kredensial yang di-cache.
Pendekatan teraman adalah menjadikan pembersihan sebagai langkah eksplisit di akhir pipeline. Hapus apa yang Anda buat. Unmount apa yang Anda mount. Hapus apa yang Anda cache. Jika platform pipeline Anda menangani sebagian dari ini secara otomatis, bagus. Namun tambahkan langkah untuk hal-hal yang mungkin terlewatkan.
Menyimpan Bukti: Bagian yang Sering Dilupakan Semua Orang
Ini adalah tindakan pasca yang paling penting, dan yang paling sering dilewati tim.
Bukti adalah catatan lengkap tentang semua yang terjadi selama pipeline run. Bukan hanya status akhir, tetapi keseluruhan cerita:
- Apa yang memicu pipeline
- Commit mana yang diproses
- Output build dan log
- Hasil pengujian, termasuk pengujian mana yang lolos dan mana yang gagal
- Laporan pemindaian keamanan
- Artifak persis yang dihasilkan (dengan hash atau URL registry)
- Log deployment
- Hasil verifikasi dari pemeriksaan pasca-deployment
Semua ini perlu disimpan di tempat yang dapat diakses. Bukan terkubur di penyimpanan internal platform CI yang kedaluwarsa setelah 30 hari. Bukan di riwayat terminal lokal seseorang. Di suatu tempat yang dapat ditanyakan berbulan-bulan atau bertahun-tahun kemudian.
Mengapa ini penting? Karena suatu hari nanti, seseorang akan bertanya:
- "Versi yang kita deploy ke produksi tiga minggu lalu, apakah sudah melalui pemindaian keamanan?"
- "Kami memiliki insiden produksi. Apakah perubahan itu diuji terhadap migrasi database?"
- "Auditor ingin melihat bukti bahwa setiap deployment telah ditinjau sebelum diluncurkan."
Tanpa bukti, Anda tidak dapat menjawab pertanyaan-pertanyaan ini. Anda harus menebak. Dan menebak dalam insiden produksi atau audit adalah cara karier hancur.
Cara Menyimpan Bukti Secara Praktis
Anda tidak perlu satu file raksasa yang berisi semuanya. Itu akan menjadi tidak terkelola dengan cepat. Sebaliknya, simpan referensi dan tautan.
Pipeline Anda harus menghasilkan ringkasan yang berisi:
- ID build dan tautan ke log build
- URL ke artifak di registry Anda
- Tautan ke laporan pengujian
- Tautan ke hasil pemindaian keamanan
- Lokasi log deployment
- Catatan persetujuan manual apa pun
Ringkasan ini dapat disimpan di sistem manajemen perubahan Anda, bucket penyimpanan objek, atau bahkan database. Formatnya bisa JSON, YAML, atau teks biasa. Yang penting adalah baik manusia maupun mesin dapat membacanya.
Beberapa tim melampirkan bukti ini ke commit atau merge request itu sendiri. Yang lain menyimpannya di repositori bukti khusus. Kedua cara sama-sama berfungsi, selama dapat dicari dan tidak dihapus secara otomatis.
Bukti Bukan Hanya untuk Auditor
Ya, auditor menyukai bukti. Namun nilai sebenarnya muncul saat debugging.
Ketika produksi rusak, pertanyaan pertama selalu: "Apa yang berubah?" Dengan bukti yang baik, Anda dapat membuka pipeline run terakhir dan melihat persis apa yang terjadi. Apakah ada pengujian yang gagal tetapi diabaikan? Apakah artifak berbeda dari yang Anda harapkan? Apakah ada perubahan konfigurasi yang tidak didokumentasikan siapa pun?
Tanpa bukti, Anda melakukan debugging secara buta. Anda mengandalkan ingatan, log chat, dan tebakan. Dengan bukti, Anda memiliki catatan faktual tentang apa yang sebenarnya terjadi.
Menutup Siklus Pipeline
Setelah notifikasi dikirim, sumber daya dibersihkan, dan bukti disimpan, siklus pipeline benar-benar selesai. Pipeline siap untuk pemicu berikutnya, dan urutan yang sama akan berulang.
Irama inilah yang membuat CI/CD dapat diandalkan. Setiap perubahan mengikuti jalur yang sama. Setiap perubahan meninggalkan jejak yang sama. Setiap perubahan menghasilkan output yang dapat diverifikasi kemudian.
Daftar Periksa Cepat untuk Tahap Pasca-Tindakan Pipeline Anda
- Notifikasi mencakup commit, penulis, lingkungan, dan status dengan tautan langsung
- Sumber daya sementara dibersihkan secara otomatis
- Log build, hasil pengujian, dan laporan pemindaian disimpan secara permanen
- Referensi artifak (URL registry, hash) dicatat
- Log deployment disimpan dan ditautkan
- Bukti disimpan di lokasi yang dapat dicari dan tidak kedaluwarsa
Kesimpulan Konkret
Pipeline yang berhenti pada "deploy berhasil" tidak lengkap. Tambahkan tiga langkah setelah deployment Anda: beri notifikasi dengan konteks yang berguna, bersihkan sumber daya sementara, dan simpan bukti yang dapat ditemukan berbulan-bulan kemudian. Langkah terakhir adalah yang menyelamatkan Anda ketika sesuatu salah. Tanpanya, Anda terbang buta. Dengannya, Anda memiliki catatan faktual yang mengubah debugging dari tebakan menjadi investigasi.