11-4 · Bab 11 · 6 menit baca

Kapan Persetujuan Manual Masih Penting dalam Pipeline Deployment Anda

Pipeline Anda hijau. Semua pemeriksaan otomatis lolos. Namun, ada kalanya otomatisasi tidak cukup. Pelajari empat situasi kritis yang masih membutuhkan persetujuan manual sebelum deploy ke produksi.

Kapan Persetujuan Manual Masih Penting dalam Pipeline Deployment Anda

Pipeline Anda hijau. Semua pemeriksaan otomatis lolos. Build berhasil dikompilasi tanpa error, unit test berjalan sukses, pemindaian keamanan tidak menemukan kerentanan kritis, dan integration test mengonfirmasi bahwa API masih merespons dengan benar. Pipeline siap untuk deploy ke produksi.

Namun, ada sesuatu yang terasa kurang tepat. Perubahan ini menulis ulang modul pembayaran. Pengujian otomatis memverifikasi bahwa kode berfungsi, tetapi mereka tidak bisa memberi tahu Anda apakah alur pembayaran baru sesuai dengan apa yang disepakati tim bisnis dengan bank. Pipeline tahu sintaksnya benar. Pipeline tidak tahu apakah logikanya sudah tepat.

Inilah saat di mana otomatisasi mencapai batasnya.

Apa yang Tidak Bisa Dilihat oleh Gerbang Otomatis

Gerbang otomatis sangat baik dalam menangkap masalah mekanis. Mereka menangkap error kompilasi, tes yang gagal, miskonfigurasi keamanan, dan kesalahan sintaks. Mereka menjalankan pemeriksaan yang sama setiap saat, secara konsisten dan tanpa lelah.

Tetapi mesin tidak bisa menilai dampak bisnis. Sebuah pipeline dapat mendeteksi bahwa kode berubah, tetapi tidak bisa menilai apakah perubahan itu mengubah alur bisnis yang kritis. Pipeline dapat memvalidasi bahwa skrip migrasi database memiliki sintaks yang benar, tetapi tidak bisa memprediksi apakah migrasi itu akan mengunci tabel besar di produksi dan menyebabkan downtime. Pipeline dapat mengonfirmasi bahwa file konfigurasi server adalah JSON yang valid, tetapi tidak bisa mengetahui apakah konfigurasi itu memutus ketergantungan untuk layanan lain.

Ini adalah situasi di mana penilaian manusia menjadi diperlukan. Pertanyaannya bukanlah apakah akan mengotomatiskan semuanya. Pertanyaannya adalah perubahan mana yang perlu dilihat oleh manusia sebelum mencapai pengguna.

Empat Situasi yang Membutuhkan Persetujuan Manual

Perubahan Kode Aplikasi Besar

Ukuran perubahan tidak diukur dari jumlah baris kode. Perubahan satu baris yang mengaktifkan fitur flag mungkin berisiko rendah. Perubahan yang menulis ulang modul inti mungkin berisiko tinggi meskipun hanya menyentuh beberapa file.

Persetujuan manual penting ketika perubahan memengaruhi alur bisnis yang kritis. Menulis ulang modul pembayaran, mengubah cara aplikasi menangani sesi pengguna, atau mengganti library inti yang menjadi dependensi banyak bagian aplikasi — perubahan ini membawa risiko yang tidak dapat dinilai sepenuhnya oleh pengujian otomatis. Tes dapat memverifikasi bahwa kode baru tidak crash, tetapi mereka tidak dapat mengonfirmasi bahwa logika bisnis baru sesuai dengan apa yang disepakati tim dengan pemangku kepentingan.

Seseorang yang memahami konteks bisnis perlu meninjau perubahan dan berkata, "Ini sesuai dengan apa yang kami rencanakan."

Perubahan Database

Perubahan database adalah salah satu sumber insiden produksi yang paling umum. Perubahan skema, indeks baru, dan migrasi data semuanya memiliki efek samping yang sulit dideteksi secara otomatis.

Cuplikan workflow GitHub Actions berikut menunjukkan bagaimana Anda dapat mewajibkan persetujuan manual untuk perubahan migrasi database:

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    # Mewajibkan persetujuan manual untuk perubahan di bawah direktori migrations/
    if: contains(github.event.head_commit.modified, 'migrations/')
    steps:
      - uses: actions/checkout@v4
      - name: Run database migration
        run: |
          echo "Applying migration..."
          # Skrip migrasi ditempatkan di sini

Dalam contoh ini, pengaturan environment: production memicu langkah persetujuan manual di GitHub Actions. Pipeline akan berhenti sampai peninjau yang ditunjuk menyetujui deployment, memastikan seorang manusia mengevaluasi migrasi sebelum mencapai produksi.

Sebuah migrasi yang menambahkan kolom ke tabel besar dapat mengunci tabel tersebut selama beberapa menit, menyebabkan aplikasi berhenti merespons. Pipeline dapat memeriksa apakah sintaks migrasi valid, tetapi tidak dapat mengevaluasi apakah migrasi tersebut aman dijalankan terhadap volume data produksi. Sebuah query yang berjalan baik di database pengembangan dengan seribu baris mungkin berkinerja buruk di database produksi dengan jutaan baris.

Tim database atau pengembang senior perlu meninjau rencana migrasi, memperkirakan dampaknya, dan menyetujui bahwa migrasi tersebut aman untuk dijalankan. Ini bukan tentang menghalangi. Ini tentang mencegah penguncian tabel selama lima menit yang dapat melumpuhkan seluruh aplikasi.

Perubahan Infrastruktur

Perubahan infrastruktur sering kali memiliki efek berantai yang sulit diprediksi. Mengubah aturan firewall jaringan, mengganti tipe instance, memperbarui versi Kubernetes, atau memodifikasi konfigurasi load balancer dapat memengaruhi layanan yang tidak Anda ketahui bergantung pada infrastruktur tersebut.

Contoh klasik: mengubah aturan firewall yang secara tidak sengaja memblokir lalu lintas dari layanan tim lain. Atau memodifikasi konfigurasi load balancer yang menyebabkan permintaan dialihkan ke backend yang salah. Pipeline dapat memvalidasi bahwa file konfigurasi benar secara sintaksis, tetapi tidak dapat mengetahui apakah konfigurasi itu sesuai dengan arsitektur aktual yang berjalan di produksi.

Tim infrastruktur perlu meninjau perubahan, memeriksa dependensi, dan mengonfirmasi bahwa perubahan itu aman untuk diterapkan.

Perubahan Apa Pun di Produksi

Produksi adalah tempat di mana pengguna nyata berinteraksi dengan aplikasi Anda. Setiap perubahan di sini membawa risiko langsung. Bahkan perubahan yang tampak kecil — memperbarui pesan error, menyesuaikan ukuran font, atau mengubah level log — dapat memiliki efek samping yang tidak terduga.

Banyak tim mengadopsi aturan sederhana: tidak ada perubahan yang masuk ke produksi tanpa persetujuan manual, terlepas dari jenis perubahannya. Aturan ini menghilangkan ambiguitas. Aturan ini memaksa seseorang untuk melihat setiap perubahan produksi dan mengambil tanggung jawab atasnya.

Cara Memutuskan Apa yang Perlu Disetujui

Tidak semua perubahan perlu ditinjau oleh manusia. Memperbaiki typo di halaman dokumentasi atau menambahkan pernyataan log baru biasanya aman untuk dilewatkan melalui gerbang otomatis. Tetapi perubahan yang memodifikasi skema database, mengubah konfigurasi produksi, atau memengaruhi alur bisnis inti harus memerlukan persetujuan manual.

Pola umumnya adalah mengklasifikasikan perubahan berdasarkan tingkat risiko:

Diagram alur berikut merangkum proses pengambilan keputusan:

flowchart TD A[Perubahan terdeteksi] --> B{Tipe perubahan?} B -->|Skema database| C[Berisiko tinggi] B -->|Infrastruktur| C B -->|Logika bisnis inti| C B -->|Konfigurasi produksi| C B -->|Perbaikan bug / docs / monitoring| D[Berisiko rendah] C --> E[Wajib persetujuan manual] D --> F[Hanya gerbang otomatis] E --> G[Tetapkan penyetuju berdasarkan keahlian] G --> H[Setujui atau tolak]

Perubahan berisiko rendah: Perbaikan bug untuk fitur non-kritis, pembaruan dokumentasi, penambahan monitoring, atau perubahan nilai konfigurasi non-fungsional. Ini dapat melewati gerbang otomatis tanpa tinjauan manual.
Perubahan berisiko tinggi: Perubahan skema database, modifikasi konfigurasi produksi, perubahan pada logika bisnis inti, upgrade library dengan perubahan yang memutuskan kompatibilitas, atau perubahan apa pun yang memengaruhi perilaku yang terlihat pengguna dalam alur kritis. Ini memerlukan persetujuan manual.

Tim Anda dapat menentukan batasannya berdasarkan konteks aplikasi dan pengalaman masa lalu. Yang penting adalah memiliki klasifikasi yang jelas sehingga semua orang tahu apa yang perlu disetujui dan apa yang tidak.

Daftar Periksa Praktis untuk Menyiapkan Persetujuan Manual

Tentukan apa yang dianggap berisiko tinggi dalam konteks aplikasi Anda. Mulailah dengan perubahan yang pernah menyebabkan insiden sebelumnya.
Klasifikasikan perubahan secara otomatis jika memungkinkan. Gunakan pesan commit, jalur file, atau penamaan cabang untuk menandai perubahan berisiko tinggi untuk ditinjau secara manual.
Tetapkan penyetuju berdasarkan keahlian. Perubahan database ditujukan ke tim DBA. Perubahan infrastruktur ditujukan ke tim platform. Perubahan logika bisnis ditujukan ke pengembang senior yang memahami domain tersebut.
Tetapkan ekspektasi waktu yang wajar. Persetujuan manual tidak boleh memakan waktu berhari-hari. Tentukan waktu respons maksimum bagi penyetuju, dan miliki jalur eskalasi jika tidak ada yang merespons.
Catat setiap keputusan persetujuan. Rekam siapa yang menyetujui apa, kapan, dan mengapa. Ini akan berharga ketika Anda perlu melacak kembali keputusan setelah sebuah insiden.

Tujuan Sebenarnya dari Persetujuan Manual

Persetujuan manual bukanlah tentang memperlambat pengiriman. Ini tentang memastikan bahwa perubahan berisiko tinggi mendapatkan perhatian yang layak sebelum mencapai pengguna. Otomatisasi menangani pemeriksaan rutin. Manusia menangani penilaian yang tidak bisa dilakukan mesin.

Tujuannya bukan untuk menghilangkan persetujuan manual. Tujuannya adalah untuk menyimpannya hanya untuk perubahan yang benar-benar membutuhkannya, sehingga tim Anda dapat bergerak cepat pada hal lainnya sambil tetap aman pada hal yang paling penting.