Best Practice #

Setelah membahas semua komponen CI/CD — pipeline design, GitHub Actions, GitLab CI, environment management, rollback, artifact, dan notifikasi — artikel ini merangkum prinsip dan pola yang membedakan pipeline yang baik dari yang sekedar berfungsi. Banyak tim membangun pipeline yang bisa men-deploy, tapi lebih sedikit yang membangun pipeline yang tim percayai dan andalkan setiap hari.

Prinsip 1: Pipeline Harus Lebih Dipercaya dari Proses Manual #

Jika tim masih lebih nyaman deploy manual daripada lewat pipeline saat situasi kritis, pipeline itu belum cukup baik. Pipeline yang baik:

✓ Mengeksekusi langkah yang sama persis setiap kali — tidak ada variasi
✓ Memberikan umpan balik yang cukup jelas saat gagal untuk bisa di-debug
✓ Bisa di-retry dengan aman tanpa efek samping
✓ Lebih cepat dari proses manual (deployment < 10 menit lebih baik)
✓ Memberi keyakinan bahwa apa yang di-test di staging adalah yang di-deploy ke production

Prinsip 2: Setiap Deployment Harus Bisa Ditelusuri #

Saat terjadi insiden, pertanyaan pertama selalu: “Apa yang berubah baru-baru ini?”

# Pastikan setiap deployment meninggalkan jejak yang jelas
# di playbook deploy.yml

- name: Tulis deployment metadata
  copy:
    content: |
      version={{ app_version }}
      deployed_at={{ ansible_date_time.iso8601 }}
      deployed_by={{ lookup('env', 'CI_JOB_URL') | default(lookup('env', 'USER')) }}
      pipeline={{ lookup('env', 'CI_PIPELINE_URL') | default('manual') }}
      git_sha={{ lookup('env', 'CI_COMMIT_SHA') | default(lookup('pipe', 'git rev-parse HEAD')) }}      
    dest: /opt/app/DEPLOYMENT_INFO
    mode: '0644'

Prinsip 3: Staging Harus Semirip Mungkin dengan Production #

Perbedaan antara staging dan production adalah sumber terbesar bug “works on staging, breaks on production”:

Perbedaan yang dapat diterima:
  - Jumlah replika (staging: 1, production: 4)
  - Ukuran database (staging: subset data)
  - Resource allocation (staging: lebih kecil)

Perbedaan yang TIDAK dapat diterima:
  - Versi OS berbeda
  - Versi software berbeda (nginx versi berbeda)
  - Konfigurasi jaringan yang fundamental berbeda
  - SSL di production tapi tidak di staging

Cara enforce: gunakan playbook yang sama dengan variabel berbeda,
bukan playbook yang berbeda per environment.

Anti-Pattern yang Paling Berbahaya #

Anti-pattern 1: Bypass pipeline saat “keadaan darurat”

Situasi: Insiden production, tekanan waktu, seseorang deploy manual.
Masalah: Deploy manual tidak tercatat, tidak tervalidasi, tidak bisa di-audit.
Solusi: Buat jalur "emergency deploy" yang masih melalui pipeline tapi lebih cepat.
        Emergency deploy boleh skip integration test tapi tidak boleh skip health check.

Anti-pattern 2: Pipeline yang tidak di-maintain

Situasi: Pipeline pernah bekerja 6 bulan lalu, sekarang sering gagal karena
         dependency yang tidak di-pin, flaky test, atau konfigurasi yang expired.
Masalah: Tim belajar untuk "re-run sampai berhasil" — validasi menjadi tidak bermakna.
Solusi: Pipeline yang gagal tanpa alasan yang jelas harus segera diperbaiki.
        Flaky test harus diperbaiki, bukan dibiarkan atau di-skip.

Anti-pattern 3: Semua orang punya akses ke semua environment

Situasi: Untuk mempercepat development, semua developer bisa deploy ke production.
Masalah: Tidak ada separation of concern, mudah terjadi kecelakaan, sulit audit.
Solusi: Gunakan RBAC — developer bisa deploy ke dev/staging, SRE approve production.
        Pipeline production memerlukan manual approval dari orang yang tepat.

Anti-pattern 4: Secret di pipeline log

# ANTI-PATTERN: secret muncul di log pipeline
- name: Deploy
  command: ansible-playbook -e "db_password={{ db_password }}" site.yml
  # db_password akan muncul di log CI!

# BENAR: gunakan vault file atau variabel yang di-mask
- name: Deploy
  command: ansible-playbook --vault-password-file /tmp/.vault_pass site.yml
  env:
    ANSIBLE_VAULT_PASSWORD_FILE: /tmp/.vault_pass

Checklist Deployment Production #

Sebelum setiap deployment ke production, pastikan:

PRE-DEPLOYMENT
  □ Semua test CI passed — tidak ada yang di-skip
  □ Deployment ke staging berhasil dan terverifikasi
  □ Smoke test staging menunjukkan semua endpoint sehat
  □ --check --diff dijalankan ke production dan output di-review
  □ Tim yang relevan sudah diberitahu (Slack #deployments)
  □ Jadwal maintenance window dikomunikasikan jika downtime diperlukan
  □ Rollback plan sudah jelas — versi berapa yang akan di-rollback-ke

DEPLOYMENT
  □ Deployment berjalan dengan serial deployment, bukan semua sekaligus
  □ Health check diverifikasi setelah setiap batch
  □ Metrik di Grafana dipantau selama deployment berlangsung

POST-DEPLOYMENT
  □ Smoke test production berhasil
  □ Error rate tidak meningkat (monitor selama 15-30 menit)
  □ Latensi tidak meningkat secara signifikan
  □ Notifikasi sukses terkirim ke Slack
  □ Deployment tercatat di log dengan versi, waktu, dan executor

Membangun Budaya Deployment yang Sehat #

"Deploy sering, deploy kecil, deploy dengan keyakinan"

Deploy sering:
  Deployment yang jarang = perubahan yang besar = risiko yang tinggi.
  Deploy setiap hari (atau lebih sering) memaksa kamu untuk membuat
  setiap deployment kecil dan mudah di-rollback.

Deploy kecil:
  Semakin kecil perubahan per deployment, semakin mudah mencari penyebab
  masalah jika ada yang salah. Feature flags memungkinkan deploy kode
  tanpa mengaktifkan fitur.

Deploy dengan keyakinan:
  Keyakinan datang dari:
  - Test coverage yang baik
  - Staging yang mencerminkan production
  - Observability yang memadai
  - Rollback yang sudah pernah dicoba dan terbukti bekerja

Ringkasan #

Pipeline lebih terpercaya dari proses manual adalah standar yang harus dicapai — jika tim bypass pipeline saat krisis, pipeline belum cukup baik.
Setiap deployment harus meninggalkan jejak yang lengkap: versi, waktu, siapa, dari pipeline mana, dan commit SHA — audit trail ini priceless saat investigasi insiden.
Staging semirip mungkin dengan production — perbedaan di konfigurasi fundamental antara environment adalah bug yang menunggu waktu untuk meledak di production.
Hindari bypass pipeline meski saat emergency — buat jalur emergency yang lebih cepat tapi tetap tervalidasi dan tercatat.
RBAC yang ketat: developer boleh deploy ke staging, production butuh approval. Ini bukan birokrasi — ini perlindungan dari kecelakaan yang serius.
Deploy sering, deploy kecil — ini bukan tentang kecepatan, tapi tentang mengurangi risiko. Perubahan kecil lebih mudah di-debug dan di-rollback.

← Sebelumnya: Notification & Reporting ← Selanjutnya: Playbook Anti Pattern