Rilis ke production adalah momen ketika kesalahan kecil berubah menjadi insiden nyata: konfigurasi dev terbawa, timeout tak terpasang, atau shutdown yang memutus koneksi pengguna di tengah transaksi. Daftar periksa berikut menghimpun empat puluh butir kesiapan dalam sepuluh kategori, masing-masing dengan rujukan chapter yang membahasnya tuntas. Gunakan daftar ini sebagai gerbang akhir sebelum tag rilis dibuat, bukan sebagai pengganti review dan test yang seharusnya sudah berjalan sejak awal.
Build dan Rilis #
Binary yang dihasilkan CI harus bersih dari jejak mesin pembangun dan terverifikasi ulang. Setiap butir di tabel ini berdampak pada reproduktibilitas saat insiden — tim harus yakin binary yang dianalisis identik dengan yang dirilis:
| Butir pemeriksaan | Rujukan |
|---|---|
Binary dibangun dengan -trimpath agar path mesin CI tidak terbocorkan | Build Flags |
Versi aplikasi di-inject lewat -ldflags "-X main.version=..." | Release Versioning |
CGO_ENABLED=0 untuk binary statis bila tidak membutuhkan cgo | Build Binary |
Target GOOS/GOARCH eksplisit di pipeline untuk tiap platform rilis | Cross Compilation |
| Binary bisa dibangun ulang dari commit tag yang sama | Release Versioning |
Test #
Gerbang kualitas otomatis menjadi bukti bahwa perilaku aplikasi masih sesuai. Test suite yang hanya lulus di laptop penulis bukan bukti:
| Butir pemeriksaan | Rujukan |
|---|---|
| Seluruh unit test lulus di lingkungan CI yang bersih | Unit Test |
go test -race lulus tanpa laporan data race | Race Detector |
| Integration test berjalan melawan dependency nyata atau kontainer uji | Testing Database |
| Coverage bertambah atau stabil — angka wajar tanpa memaksa 100% | Coverage |
| Benchmark jalur kritis dibandingkan bila ada perubahan performa | Benchmark |
Konfigurasi #
Konfigurasi produksi harus aman sejak nilai default. Kesalahan paling umum: default yang enak untuk development jalan tanpa sengaja di production:
| Butir pemeriksaan | Rujukan |
|---|---|
| Semua konfigurasi dibaca dari environment variable, bukan hardcode | Environment Production |
| Nilai default aman untuk production, bukan default mode development | Environment Production |
| Secret berasal dari secret manager atau environment yang terlindungi | Secure Configuration |
| Validasi konfigurasi berjalan saat startup dengan pesan galat yang jelas | Environment Production |
| Konfigurasi dimuat sekali saat startup, bukan pada setiap request | Environment Production |
Logging #
Log adalah mata tim saat insiden. Log terstruktur membuat pertanyaan “apa yang terjadi” bisa dijawab dengan query, bukan membaca ribuan baris:
| Butir pemeriksaan | Rujukan |
|---|---|
Log terstruktur key-value memakai log/slog | log/slog |
| Level log dapat diubah tanpa restart saat dibutuhkan | Log Level |
| Setiap baris log request membawa request ID | Request ID |
| Tidak ada data sensitif (password, token) yang masuk log | Secure Logging |
Observability #
Kesehatan layanan harus terlihat dari luar tanpa masuk ke mesin. Empat pilar — health, metrik, tracing, dan diagnostik — menutup kebutuhan itu:
| Butir pemeriksaan | Rujukan |
|---|---|
Endpoint /healthz (liveness) dan /readyz (readiness) tersedia | Health, Readiness, Liveness |
| healthz tetap ringan — tidak memeriksa dependency berat | Health, Readiness, Liveness |
| Metrik inti terekspos: latensi, tingkat error, throughput | Metrics |
| Format eksposur metrik mengikuti standar Prometheus | Prometheus |
| Distributed tracing aktif untuk lintas layanan | Distributed Tracing |
Graceful Shutdown #
Proses yang dimatikan harus pergi dengan sopan: menyelesaikan request berjalan, menutup koneksi, dan menghentikan worker secara bersih:
| Butir pemeriksaan | Rujukan |
|---|---|
Sinyal SIGTERM ditangani dan server berhenti menerima koneksi baru | Graceful Shutdown |
Pemanggilan server.Shutdown dibungkus context ber-timeout | Graceful Shutdown |
| Worker latar menyelesaikan tugas berjalan sebelum proses keluar | Graceful Shutdown Production |
Timeout #
Operasi tanpa batas waktu adalah insiden yang menunggu jadwal. Setiap panggilan lintas proses — jaringan, database, layanan lain — harus punya deadline:
| Butir pemeriksaan | Rujukan |
|---|---|
| HTTP client mengatur timeout, bukan memakai default tanpa batas | net/http Client |
HTTP server mengatur ReadTimeout dan WriteTimeout | net/http Server |
| Query database dibungkus context dengan timeout | Context dan Query Timeout |
| Deadline context diteruskan ke panggilan layanan lain | Context pada HTTP |
Koneksi #
Koneksi adalah sumber daya terbatas yang diam-diam habis. Pool yang tak dibatasi membuat gangguan satu dependency menjalar ke seluruh aplikasi:
| Butir pemeriksaan | Rujukan |
|---|---|
Connection pool database dibatasi (MaxOpenConns, MaxIdleConns) | Connection Pool |
Umur koneksi dibersihkan (ConnMaxLifetime, ConnMaxIdleTime) | Database Connection Management |
| Koneksi HTTP client di-reuse dengan batas per host | Timeout dan Connection |
Deployment #
Artefak rilis harus kecil, minim permukaan serangan, dan berjalan dengan hak paling rendah. Prinsipnya: image berisi aplikasi, bukan lingkungan pengembangan:
| Butir pemeriksaan | Rujukan |
|---|---|
| Image dibangun multi-stage sehingga layer akhir kecil tanpa toolchain | Docker Multi-Stage Build |
| Proses berjalan sebagai user non-root | Containerization |
| Image dasar minimal (distroless atau alpine) dengan binary statis | Containerization |
| Resource limit CPU dan memori diatur di orchestrator | Containerization |
Rollback dan Dokumentasi #
Rencana rilis yang matang selalu punya pintu keluar. Kemampuan kembali cepat ke versi sehat sering lebih berharga daripada kecepatan rilis itu sendiri:
| Butir pemeriksaan | Rujukan |
|---|---|
| Strategi rollback teruji: versi sebelumnya dapat ditarik dalam hitungan menit | Rollback dan Recovery |
| Runbook insiden dan README operasional tersedia serta mutakhir | Rollback dan Recovery |
Daftar ini paling berguna saat dicetak sebagai bagian checklist rilis internal tim — centang per kategori, catat pengecualian beserta alasannya, dan simpan bersama tag rilis sebagai catatan keputusan. Kapan pun kita butuh memperdalam satu butir, empat puluh tautan di atas mengarah ke chapter yang membahasnya lengkap. Setelah aplikasi berjalan stabil, sumber belajar berikutnya adalah dokumentasi dan komunitas resmi — dirangkum di chapter Sumber Belajar Resmi .
Referensi #
- Go Diagnostics — alat diagnosis resmi untuk produksi.
- Multi-stage builds — pola image kecil yang diminta kategori deployment.
- Go Release History — dasar kebijakan versi toolchain saat rilis.