19.2 Deployment, Release, dan Keputusan Desain

Seorang arsitek di sebuah perusahaan fintech bercerita bahwa timnya punya aturan tidak tertulis: setiap deploy ke production harus dilakukan pada hari Jumat malam. Alasannya, kalau ada yang rusak, tim punya akhir pekan untuk memperbaiki. Saya tidak bisa menyembunyikan keterkejutan saya. Ia tersenyum masam dan berkata, “Kami tahu ini tidak ideal, tapi ini satu-satunya cara agar tim lain tidak terganggu.”

Situasi ini menunjukkan kebingungan yang cukup umum: menyamakan deployment dengan release. Deployment adalah proses memindahkan kode ke environment tertentu. Release adalah keputusan untuk membuat fitur itu bisa diakses oleh pengguna. Keduanya tidak harus terjadi bersamaan. Dan ketika seorang arsitek tidak membedakan keduanya, keputusan desain yang sudah dibuat di diagram bisa hancur dalam satu kali deploy.

Bayangkan tim menerapkan arsitektur microservices yang rapi. Setiap service punya batasan yang jelas, antarmuka yang terdefinisi, dan skema data yang sudah disepakati. Kemudian seseorang melakukan deploy langsung ke production tanpa melalui jalur pemrosesan yang memverifikasi keputusan-keputusan itu. Service A tiba-tiba memanggil endpoint yang sudah dihapus di Service B. Data masuk dengan format yang tidak dikenali. Diagram arsitektur yang indah itu tidak lagi mencerminkan kenyataan.

Di sinilah CI/CD jalur pemrosesan menjadi alat arsitektur, bukan sekadar alat engineering. Jalur Pemrosesan yang baik bukan hanya menjalankan tes unit dan build. Ia juga menjalankan pemeriksaan yang menjaga keputusan desain: Apakah antarmuka antar service masih sesuai kontrak? Apakah konfigurasi environment sudah benar? Apakah ada dependensi yang berubah tanpa pemberitahuan? Apakah skema database masih kompatibel dengan versi sebelumnya? Semua ini adalah pertanyaan arsitektural yang harus dijawab sebelum kode menyentuh production.

Berikut contoh pipeline GitHub Actions yang memverifikasi kontrak antar service dan kompatibilitas skema sebelum deploy.

name: arsitektur-pipeline
on: [push]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Contract Test
        run: |
          cd service-a
          npm run contract-test:provider
      - name: Schema Check
        run: |
          cd database
          npx db-migrate check-compatibility
      - name: Config Validation
        run: |
          for env in staging production; do
            node validate-config.js --env $env
          done
  deploy-canary:
    needs: verify
    runs-on: ubuntu-latest
    steps:
      - name: Deploy 10% Traffic
        run: |
          kubectl set image deployment/service-a \
            service-a=registry.example/service-a:${{ github.sha }}
          kubectl scale deployment/service-a --replicas=1

Pembedaan deployment dan release memberi arsitek ruang bernapas. Deployment bisa dilakukan kapan saja—bahkan beberapa kali sehari—ke environment staging atau production yang tidak melayani trafik pengguna. Release, di sisi lain, adalah keputusan bisnis yang diatur oleh fitur flag, gradual rollout, atau persentase trafik. Arsitek bisa memastikan bahwa kode sudah berada di production, berjalan di infrastruktur nyata, tetapi belum memengaruhi pengguna sampai keputusan release diambil.

Berikut adalah diagram yang menunjukkan alur dari commit hingga production, dengan titik-titik verifikasi keputusan arsitektur.

flowchart TD A[Commit] --> B[CI/CD Pipeline] B --> C[Unit Test] C --> D[Contract Check] D --> E[Config Validation] E --> F[Schema Compatibility] F --> G{Deploy ke Environment} G --> H[Staging / Non-Prod] G --> I[Production tanpa trafik] I --> J{Feature Flag / Release Decision} J --> K[Release ke Pengguna] J --> L[Rollback / Roll-forward] style B fill:#f9f,stroke:#333,stroke-width:2px style J fill:#ff9,stroke:#333,stroke-width:2px

Ketika ada yang salah, arsitek perlu dua mekanisme: rollback dan roll-forward. Rollback mengembalikan sistem ke versi sebelumnya. Roll-forward memperbaiki masalah dengan versi baru yang lebih cepat daripada mencari akar masalah. Keduanya harus sudah dipikirkan saat mendesain arsitektur, bukan saat insiden terjadi. Seorang arsitek yang baik memastikan bahwa jalur pemrosesan mendukung kedua opsi ini, dan bahwa tim tahu kapan memakai yang mana.

Yang paling penting, jalur pemrosesan menjadi catatan keputusan arsitektur yang terus hidup. Setiap kali jalur pemrosesan gagal karena melanggar aturan arsitektural, itu adalah feedback langsung bahwa ada ketidaksesuaian antara desain dan implementasi. Arsitek tidak perlu menunggu rapat review atau audit bulanan. Ia bisa melihat sendiri, dari dashboard jalur pemrosesan, apakah keputusan desainnya masih dijaga oleh tim engineering.

Setelah mekanisme deployment dan release berjalan, pertanyaan berikutnya adalah: bagaimana arsitek tahu bahwa sistem yang sudah berjalan di production benar-benar berperilaku seperti yang diharapkan? Jawabannya tidak ada di diagram atau jalur pemrosesan. Jawabannya ada di data dari production itu sendiri.

Deployment View
Deployment View