Production dalam CI/CD — apa itu, tahapan dan lingkungan dalam pengembangan

Apa itu Production dalam CI/CD

Production dalam konteks CI/CD — adalah tahap akhir siklus hidup aplikasi, di mana kode setelah melewati semua tahap pembuatan dan pengujian menjadi tersedia untuk pengguna akhir. Berbeda dengan lingkungan pengembangan dan staging, lingkungan production bekerja dengan data dan beban nyata, yang memberikan persyaratan khusus untuk keandalan dan kinerja.

Peran lingkungan production

Lingkungan production bukan hanya server, tetapi seluruh infrastruktur, termasuk load balancer, database, lapisan cache, CDN, dan sistem monitoring. Setiap komponen harus toleran terhadap kesalahan dan skalabel. Dalam pengembangan mobile, production juga mencakup layanan backend, gateway API, dan infrastruktur push yang memastikan operasi aplikasi klien.

Persyaratan lingkungan production

Lingkungan production harus memenuhi kriteria ketat: ketersediaan 99.9% dan lebih tinggi, waktu respons API tidak lebih dari 200 ms, dukungan pemulihan bencana (RTO dan RPO dalam batas SLA). Untuk aplikasi mobile, diperlukan tambahan monitoring crash (pelaporan kesalahan), analitik penggunaan, dan platform A/B untuk eksperimen. Pipeline CI/CD memastikan kepatuhan terhadap persyaratan ini melalui pemeriksaan otomatis sebelum setiap deployment.

Tahapan deployment ke production

Deployment ke production — adalah proses multi-tahap yang diotomatiskan melalui pipeline CI/CD. Setiap tahap mencakup pemeriksaan yang mencegah masuknya kode cacat ke produksi. Mari kita lihat tahapan kunci pada contoh pipeline tipikal untuk aplikasi mobile.

Pipeline CI/CD untuk production

Pipeline dimulai dengan commit ke cabang utama repositori. Setelah push, pembuatan otomatis dan unit test dimulai, kemudian integration test dan pemeriksaan kualitas kode. Setelah berhasil melewati semua tahap, artefak dipublikasikan di registri build dan di-deploy ke staging untuk verifikasi akhir. Hanya setelah konfirmasi di staging, pipeline beralih ke deployment ke production.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

Otomatisasi deployment

Deployment otomatis ke production menggunakan strategi zero-downtime deployment: rolling update, blue-green deployment, atau canary release. Pada rolling update, instance aplikasi baru secara bertahap menggantikan yang lama tanpa menghentikan layanan. Blue-green deployment mempertahankan dua lingkungan identik dan mengalihkan traffic secara instan, memungkinkan pengembalian cepat jika terjadi masalah. Pemilihan strategi tergantung pada kekritisan layanan dan waktu henti yang diizinkan. Untuk aplikasi mobile, deployment ke production mencakup publikasi di toko aplikasi (App Store Connect, Google Play Console) dengan peluncuran bertahap, yang memerlukan integrasi tambahan CI/CD dengan API toko untuk otomatisasi proses publikasi, termasuk mengunggah file biner, mengisi metadata, dan mengirim untuk ditinjau.

Pemeriksaan pasca-deployment

Setelah deployment berhasil ke production, pipeline CI/CD menjalankan serangkaian smoke-test yang memeriksa fungsionalitas dasar layanan: ketersediaan endpoint, kebenaran respons API, waktu respons dalam batas normal. Untuk aplikasi mobile, tambahan diperiksa kemungkinan otentikasi, sinkronisasi data, dan berfungsinya integrasi pembayaran dengan benar. Jika smoke-test gagal, pipeline secara otomatis memulai rollback ke versi stabil sebelumnya dan mengirim pemberitahuan ke tim. Monitoring setelah deployment berlanjut selama 30-60 menit dengan tingkat alert yang ditingkatkan — ini adalah jendela untuk menemukan masalah yang tidak tercakup oleh pengujian otomatis.

Perbedaan production dengan lingkungan pengujian

Perbedaan utama antara production dan lingkungan yang kurang ketat — bekerja dengan data dan beban pengguna nyata. Lingkungan staging ditujukan untuk verifikasi akhir sebelum rilis, tetapi menggunakan data sintetis atau anonim. Production sebaliknya memproses transaksi langsung, data pribadi, dan operasi kritis, yang memerlukan pendekatan manajemen yang fundamental berbeda.

Konfigurasi dan infrastruktur

Konfigurasi lingkungan production harus benar-benar terisolasi dari lingkungan lain. Ini menyangkut variabel lingkungan, string koneksi ke database, kunci API, dan sertifikat. Infrastruktur production biasanya diduplikasi di beberapa zona ketersediaan (availability zones) untuk memastikan toleransi kesalahan. Untuk aplikasi mobile, production juga mencakup konfigurasi Apple App Store dan Google Play yang tidak ada di build pengujian.

Manajemen data

Di production, penggunaan data nyata untuk pengujian sangat dilarang — untuk ini ada lingkungan staging dan development. Semua perubahan struktur database harus melalui migrasi yang diterapkan secara otomatis oleh pipeline CI/CD. Pencadangan data production dilakukan sesuai jadwal dengan pemeriksaan integritas cadangan otomatis. Retention policy menentukan periode penyimpanan cadangan sesuai dengan persyaratan GDPR dan regulator lainnya.

Monitoring infrastruktur production

Monitoring production — adalah proses berkelanjutan pengumpulan dan analisis metrik, log, dan trace. Tanpa monitoring yang lengkap, tidak mungkin menjamin SLA dan mendeteksi insiden tepat waktu. Pendekatan modern terhadap monitoring didasarkan pada tiga pilar: metrik (indikator numerik), log (catatan peristiwa terstruktur), dan trace (pelacakan permintaan).

Metrik utama

Metrik utama lingkungan production meliputi: uptime (ketersediaan layanan), latency (penundaan respons), error rate (persentase kesalahan), throughput (kapasitas) dan saturation (tingkat beban sumber daya). Untuk aplikasi mobile, metrik waktu mulai, frekuensi crash (crash-free rate) dan waktu sinkronisasi data sangat penting. Alert dikonfigurasi berdasarkan SLO (Service Level Objectives), sehingga tim menerima pemberitahuan sebelum pelanggaran SLA.

Alat monitoring

Untuk monitoring infrastruktur production digunakan platform khusus: Datadog, New Relic, Grafana + Prometheus untuk pengumpulan metrik, Sentry dan Crashlytics untuk pelacakan kesalahan di aplikasi mobile. Log dipusatkan melalui ELK stack (Elasticsearch, Logstash, Kibana) atau Splunk. Pelacakan permintaan dilakukan dengan Jaeger atau Zipkin. Semua alat terintegrasi dengan pipeline CI/CD untuk pembuatan dashboard otomatis saat deployment layanan baru. Sistem incident response (PagerDuty, Opsgenie) menerima alert dari semua alat monitoring dan secara otomatis menugaskan petugas yang bertanggung jawab berdasarkan rotasi dan aturan eskalasi. Runbook untuk setiap jenis insiden disimpan di repositori dan diberi versi bersama dengan kode, menjamin keaktualan instruksi pemulihan.

Keamanan lingkungan production

Keamanan lingkungan production — adalah sistem perlindungan multi-level yang mencakup infrastruktur, data, akses, dan proses deployment. Setiap level harus dikonfigurasi sehingga kompromi satu tidak menyebabkan kompromi seluruh sistem. Pipeline CI/CD memainkan peran kunci dalam memastikan keamanan melalui pemeriksaan otomatis, pemindaian kerentanan, dan kontrol kepatuhan di setiap tahap pipeline.

Akses dan peran

Akses ke lingkungan production dibatasi ketat berdasarkan prinsip hak istimewa minimum. Pengembang tidak memiliki akses langsung ke server production — semua perubahan melalui pipeline CI/CD dengan mekanisme persetujuan. Untuk akses darurat digunakan kredensial sementara dengan rotasi otomatis dan pencatatan tindakan yang lengkap. Prinsip empat mata (setiap operasi memerlukan persetujuan dua orang) adalah standar untuk operasi production.

Audit perubahan

Setiap perubahan di production dicatat dalam sistem audit: siapa yang memulai deployment, commit mana yang di-deploy, pemeriksaan apa yang dilakukan, berapa lama deployment berlangsung. Integrasi CI/CD dengan sistem manajemen insiden (PagerDuty, Opsgenie) memungkinkan pembuatan tiket otomatis saat deployment gagal atau pelanggaran SLO. Semua log production disimpan di penyimpanan yang tidak dapat diubah dengan periode retensi minimal 90 hari sesuai dengan persyaratan SOC2 dan ISO 27001.