Pipeline rilis human-in-the-loop tanpa AI bukan berarti kembali ke proses manual yang lambat. Intinya adalah membedakan dengan jelas mana pekerjaan yang harus diotomasi secara konsisten oleh CI/CD, dan mana keputusan yang sebaiknya tetap dibuat manusia karena menyangkut konteks bisnis, risiko, atau kualitas yang belum bisa dinilai hanya dari sinyal otomatis.

Untuk tim developer, targetnya bukan “sebanyak mungkin otomatis”, melainkan otomasi untuk pekerjaan deterministik dan intervensi manusia untuk keputusan bernilai tinggi. Jika batas ini dirancang dengan baik, pipeline tetap cepat, audit trail tetap rapi, dan developer experience tidak rusak oleh approval yang tidak perlu.

Kapan otomasi wajib dipakai, kapan keputusan tetap manual

Pemisahan ini adalah fondasi utama. Banyak pipeline rilis menjadi lambat bukan karena ada approval manusia, tetapi karena otomasi tidak cukup kuat di langkah yang seharusnya objektif dan berulang.

Yang sebaiknya wajib diotomasi

  • Formatting dan linting dasar: pekerjaan ini deterministik. Jika aturan sudah jelas, mesin yang menegakkan.
  • Unit test dan integration test yang stabil: jika hasilnya biner lulus/gagal, tidak ada alasan menunggu review manual.
  • Build artifact: image, bundle, package, checksum, dan metadata rilis sebaiknya dibuat sistem agar reproducible.
  • Deploy ke preview atau staging environment: provisioning dan deployment harus bisa diulang tanpa langkah manual yang rawan drift.
  • Pembuatan changelog terstruktur: draf dapat dihasilkan otomatis dari commit atau pull request, lalu ditinjau manusia sebelum rilis.
  • Pencatatan audit trail: siapa yang memicu rilis, commit mana yang dirilis, approval siapa, dan rollback kapan harus tercatat otomatis.

Yang biasanya tetap perlu keputusan manusia

  • Keputusan layak rilis: misalnya ada bug minor yang diketahui, tetapi dianggap dapat diterima untuk kebutuhan bisnis tertentu.
  • Review perubahan berisiko tinggi: migrasi database besar, perubahan skema API, atau perubahan perilaku billing.
  • Validasi kualitas non-deterministik: UX copy, alur onboarding, atau perilaku aplikasi yang sulit dinilai dari test otomatis saja.
  • Keputusan rollback atau lanjut mitigasi: alarm bisa otomatis, tetapi keputusan operasional sering butuh konteks manusia.

Prinsip praktisnya sederhana: otomasi memverifikasi fakta; manusia mengambil keputusan. Jika pipeline Anda membalik ini, proses biasanya menjadi lambat dan membingungkan.

Arsitektur pipeline rilis human-in-the-loop yang sehat

Pipeline yang sehat biasanya terdiri dari beberapa lapisan. Setiap lapisan mempersempit risiko sebelum sampai ke produksi, sehingga approval manusia terjadi di titik yang masuk akal, bukan di setiap langkah kecil.

1. Guardrail lokal: pre-commit lint dan format

Masalah paling murah diperbaiki adalah yang tertangkap sebelum kode dikirim ke remote. Karena itu, jalankan formatting dan lint ringan di mesin developer melalui pre-commit hook.

Tujuannya bukan mengganti CI, tetapi mengurangi umpan balik yang terlambat. Developer tidak perlu menunggu pipeline hanya untuk tahu bahwa ada spasi salah, import tidak terpakai, atau file tidak mengikuti gaya tim.

# .pre-commit-config.yaml (contoh generik jika memakai pre-commit framework)
repos:
  - repo: local
    hooks:
      - id: format
        name: format
        entry: make format
        language: system
        pass_filenames: false
      - id: lint
        name: lint
        entry: make lint-changed
        language: system
        pass_filenames: false

Kenapa ini efektif: lint/format adalah sinyal cepat dan murah. Menjalankannya di awal mempercepat feedback loop tanpa menambah beban approval.

Trade-off: jangan terlalu banyak memasukkan test berat ke pre-commit. Jika hook lokal memakan waktu lama, developer akan mencari cara melewatinya.

2. Test bertahap di CI

Semua test tidak harus berjalan pada tahap yang sama. Pipeline yang baik memisahkan test berdasarkan biaya, cakupan, dan nilai sinyalnya.

  • Tahap cepat: lint, type check, unit test singkat.
  • Tahap menengah: integration test, API contract test, build validation.
  • Tahap lebih mahal: end-to-end test, security scan tertentu, atau test performa ringan jika relevan.

Dengan model bertahap, kegagalan sederhana menghentikan pipeline lebih awal. Ini menghemat waktu komputasi dan mempercepat feedback bagi developer.

3. Preview environment per pull request atau merge request

Preview environment sangat berguna untuk pendekatan human-in-the-loop karena memberi manusia konteks nyata saat meninjau perubahan. Reviewer tidak hanya membaca diff, tetapi bisa mengakses aplikasi hasil deploy.

Ini sangat membantu untuk:

  • validasi UI/UX,
  • cek integrasi antar-layanan,
  • memastikan konfigurasi build benar,
  • menguji skenario bisnis yang sulit direpresentasikan dalam test otomatis.

Batas penting: preview environment bukan pengganti staging atau test otomatis. Ia adalah alat untuk memperkaya keputusan manusia, bukan alasan untuk mengurangi kualitas test.

4. Approval gate hanya di titik bernilai tinggi

Approval gate sebaiknya diletakkan setelah bukti teknis dasar terkumpul: lint lulus, test inti lulus, artifact dibuat, dan preview tersedia bila perlu. Approval yang datang terlalu awal hanya mengunci antrean tanpa informasi cukup.

Biasanya gate yang masuk akal adalah:

  • Promosi ke staging untuk perubahan berisiko tinggi.
  • Promosi ke production setelah verifikasi teknis selesai.
  • Eksekusi migration sensitif jika dampaknya sulit dipulihkan.

Jika setiap commit ke branch utama selalu membutuhkan persetujuan operasional manual, kemungkinan desain pipeline Anda belum efisien.

Flow konkret: dari commit sampai rilis

Berikut alur yang realistis untuk banyak tim aplikasi web atau backend.

  1. Developer commit kode.
  2. Pre-commit menjalankan format dan lint ringan.
  3. Push ke branch memicu CI tahap cepat: lint penuh, unit test, type check.
  4. Jika lolos, CI menjalankan build artifact dan integration test.
  5. CI membuat preview environment untuk branch atau pull request.
  6. Reviewer memeriksa kode dan, bila relevan, mencoba preview.
  7. Setelah merge, pipeline branch utama membuat artifact final dan men-deploy ke staging.
  8. Checklist release ditinjau manusia.
  9. Versi ditentukan dengan semantic versioning, changelog diperbarui.
  10. Approval gate untuk produksi diberikan oleh pihak yang bertanggung jawab.
  11. Deploy ke production dilakukan otomatis dari artifact yang sama yang sudah diverifikasi.
  12. Observability dipantau; jika ada masalah, rollback mengikuti prosedur yang sudah ditetapkan.

Perhatikan bahwa manusia hadir pada review, penilaian risiko, dan approval rilis, bukan pada kegiatan mekanis seperti build atau copy-paste catatan rilis.

Contoh struktur GitHub Actions

Contoh berikut menunjukkan pemisahan tahap cepat, build, preview, dan approval produksi. Ini bukan template universal, tetapi cukup menggambarkan struktur yang sehat.

name: release-pipeline

on:
  pull_request:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  fast-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup
        run: make ci-setup
      - name: Format check
        run: make format-check
      - name: Lint
        run: make lint
      - name: Unit test
        run: make test-unit

  build-and-integration:
    runs-on: ubuntu-latest
    needs: fast-checks
    steps:
      - uses: actions/checkout@v4
      - name: Setup
        run: make ci-setup
      - name: Build artifact
        run: make build
      - name: Integration test
        run: make test-integration
      - name: Upload artifact
        run: make publish-artifact

  preview:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    needs: build-and-integration
    steps:
      - uses: actions/checkout@v4
      - name: Deploy preview
        run: make deploy-preview

  staging:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    needs: build-and-integration
    steps:
      - uses: actions/checkout@v4
      - name: Deploy staging
        run: make deploy-staging

  release:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    needs: staging
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Create release notes draft
        run: make changelog-draft
      - name: Deploy production
        run: make deploy-production

Di GitHub Actions, environment: production sering dipakai untuk menambahkan protection rule atau approval sebelum job produksi berjalan. Ini cocok untuk approval gate karena artifact sudah dibangun lebih dulu, sehingga manusia hanya memutuskan promote or not, bukan menjalankan proses teknis manual.

Contoh struktur GitLab CI

Jika tim memakai GitLab CI, ide utamanya sama: pisahkan tahap verifikasi, build, preview/staging, dan produksi manual.

stages:
  - validate
  - build
  - preview
  - staging
  - release

validate:
  stage: validate
  script:
    - make ci-setup
    - make format-check
    - make lint
    - make test-unit

build:
  stage: build
  script:
    - make build
    - make test-integration
    - make publish-artifact
  needs:
    - validate

preview:
  stage: preview
  script:
    - make deploy-preview
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  needs:
    - build

staging:
  stage: staging
  script:
    - make deploy-staging
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  needs:
    - build

release_production:
  stage: release
  script:
    - make changelog-draft
    - make deploy-production
  when: manual
  allow_failure: false
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  needs:
    - staging

Pola when: manual dipakai untuk approval gate. Namun jangan jadikan semua job penting manual. Manual hanya untuk titik keputusan, bukan pengganti test atau deployment reproducible.

Checklist review dan release yang benar-benar berguna

Checklist buruk hanya menambah formalitas. Checklist yang baik memaksa tim memeriksa risiko yang memang sering terlewat.

Template checklist review perubahan

  • Apakah perubahan ini mengubah perilaku publik API, event, atau skema data?
  • Apakah ada migration database? Jika ya, apakah aman untuk deploy bertahap?
  • Apakah ada flag, fallback, atau cara mematikan fitur tanpa redeploy penuh?
  • Apakah log, metric, atau trace yang dibutuhkan untuk memantau perubahan sudah ada?
  • Apakah preview environment sudah diperiksa untuk alur utama?
  • Apakah ada dependency eksternal baru atau perubahan izin akses?

Template checklist release

# Release Checklist

## Kesiapan teknis
- [ ] Lint, unit test, dan integration test lulus
- [ ] Artifact rilis dibuat dari commit yang akan dirilis
- [ ] Preview/staging telah diverifikasi untuk skenario utama
- [ ] Migration database ditinjau dan punya rencana rollback/mitigasi
- [ ] Monitoring dashboard dan alert terkait sudah siap

## Kesiapan produk/operasional
- [ ] Changelog diringkas dengan dampak ke pengguna
- [ ] Perubahan breaking sudah dikomunikasikan bila ada
- [ ] Waktu rilis sesuai dengan kapasitas on-call atau penanggung jawab

## Approval
- [ ] Reviewer teknis menyetujui
- [ ] Penanggung jawab rilis menyetujui promosi ke production

## Pasca-rilis
- [ ] Verifikasi smoke test produksi selesai
- [ ] Error rate, latency, dan log dipantau setelah deploy
- [ ] Jika perlu rollback, prosedur dan owner sudah jelas

Kenapa checklist ini bekerja: isinya berbasis risiko nyata. Ia tidak menanyakan hal yang sudah dibuktikan CI, kecuali untuk memastikan evidence itu memang dilihat dalam konteks rilis.

Semantic versioning dan changelog: jangan diserahkan ke ingatan manusia

Dalam pipeline rilis human-in-the-loop tanpa AI, manusia tetap meninjau makna rilis, tetapi proses dasarnya sebaiknya disiplin dan terstruktur.

Semantic versioning

Gunakan semantic versioning jika produk Anda cocok dengan model itu:

  • MAJOR untuk perubahan tidak kompatibel.
  • MINOR untuk penambahan fitur yang kompatibel.
  • PATCH untuk perbaikan bug yang kompatibel.

Keputusan versi bisa dibantu oleh konvensi commit atau label pull request, tetapi validasi akhirnya sebaiknya tetap dilakukan manusia untuk menghindari salah klasifikasi perubahan breaking.

Changelog

Draf changelog dapat dihasilkan otomatis dari commit atau merge request, lalu diperiksa agar bahasanya masuk akal untuk pembaca internal atau pengguna.

Yang sering salah adalah menjadikan changelog daftar commit mentah. Changelog yang berguna harus merangkum:

  • fitur baru,
  • bug fix penting,
  • breaking change,
  • langkah operasional yang perlu diketahui.

Otomasi membantu mengumpulkan data; manusia memastikan narasinya akurat.

Rollback, mitigasi, dan audit trail

Pipeline rilis yang bagus bukan hanya soal deploy sukses, tetapi juga soal cara gagal dengan aman.

Rollback

Rollback perlu dirancang sejak awal, bukan ditulis saat insiden. Minimal, tim perlu tahu:

  • apakah rollback cukup dengan redeploy artifact sebelumnya,
  • apakah migration database dapat dibalik,
  • apakah perlu strategi roll-forward daripada rollback,
  • siapa yang berwenang memutuskan rollback.

Untuk sistem dengan perubahan data yang tidak mudah dibalik, rollback kode saja mungkin tidak cukup. Karena itu, approval manusia tetap penting untuk perubahan yang menyentuh data permanen.

Audit trail

Audit trail sebaiknya tercatat otomatis oleh sistem CI/CD dan platform deploy. Data minimum yang berguna:

  • commit hash atau tag yang dirilis,
  • waktu deploy,
  • siapa yang memberikan approval,
  • siapa yang memicu pipeline,
  • hasil test yang menjadi dasar keputusan,
  • tautan ke changelog, tiket, atau pull request terkait.

Audit trail penting bukan hanya untuk kepatuhan, tetapi juga debugging. Saat insiden terjadi, tim bisa cepat menjawab: apa yang berubah, kapan, dan atas persetujuan siapa?

Metrik untuk memastikan proses tidak menjadi lambat

Tanpa metrik, tim mudah jatuh ke dua ekstrem: approval berlebihan atau otomasi buta. Beberapa metrik yang relevan:

Lead time for changes

Ukur waktu dari perubahan siap digabung atau digabung ke branch utama sampai berjalan di produksi. Jika lead time terus naik, cari bottleneck: test lambat, preview rapuh, atau approval terlalu tersentralisasi.

Change failure rate

Berapa persen rilis menyebabkan insiden, rollback, atau hotfix. Jika rendah, approval gate mungkin cukup efektif. Jika tinggi, masalahnya bisa pada test yang tidak merepresentasikan risiko nyata atau checklist yang terlalu formal.

False positive lint atau test failure rate yang tidak relevan

Jika lint atau test sering gagal untuk alasan yang tidak penting atau tidak stabil, developer akan kehilangan kepercayaan pada pipeline. Ukur berapa banyak kegagalan yang akhirnya dianggap noise. Sinyal otomatis yang buruk memperlambat lebih banyak daripada approval manusia yang tepat sasaran.

Waktu tunggu approval

Ukur durasi dari pipeline siap rilis sampai approval diberikan. Jika tinggi, masalahnya bisa organisasi, bukan tooling. Solusinya bisa berupa rotasi release owner, aturan auto-assign reviewer, atau pembatasan approval hanya pada perubahan tertentu.

Tujuan metrik bukan membuktikan bahwa manual selalu buruk atau otomatis selalu baik. Tujuannya adalah menemukan titik di mana intervensi manusia memberi nilai lebih besar daripada biayanya.

Kesalahan umum saat menerapkan pipeline human-in-the-loop

  • Approval terlalu banyak: setiap tahap butuh klik manusia. Hasilnya antrean, bukan kontrol.
  • Preview environment rapuh: reviewer diminta mengecek hal yang infrastrukturnya sendiri tidak stabil.
  • Checklist menyalin output CI: manusia diminta menegaskan ulang hal yang sudah diverifikasi mesin.
  • Rollback tidak diuji: prosedur ada di dokumen, tetapi tidak realistis saat insiden.
  • Semua perubahan diperlakukan sama: bugfix kecil dan migrasi data besar tidak perlu proses identik.
  • Test lambat dan tidak berlapis: pipeline menunggu terlalu lama sebelum memberi sinyal awal.

Strategi agar tetap cepat tanpa jatuh ke anti-otomasi

Pipeline rilis human-in-the-loop tanpa AI yang efektif biasanya mengikuti beberapa aturan praktis:

  • Automate the obvious: semua yang deterministik dan sering diulang harus otomatis.
  • Human review the risky: manusia fokus pada risiko, bukan formalitas.
  • Promote immutable artifacts: jangan build ulang untuk produksi jika artifact sudah lolos di tahap sebelumnya.
  • Gunakan approval berbasis risiko: misalnya hanya untuk migration tertentu, perubahan auth, billing, atau breaking change.
  • Jaga feedback loop cepat: lint lokal, test bertahap, dan preview yang konsisten jauh lebih berharga daripada menambah satu approval lagi.

Pendekatan ini bukan anti-otomasi. Justru ia menganggap otomasi sangat penting, tetapi ditempatkan pada pekerjaan yang memang cocok diotomasi. Sementara itu, manusia dipakai di titik yang benar-benar membutuhkan penilaian, konteks, dan tanggung jawab.

Penutup

Pipeline rilis human-in-the-loop tanpa AI paling berguna ketika tim ingin menjaga kualitas keputusan tanpa mengorbankan kecepatan pengiriman. Kuncinya adalah membangun guardrail otomatis untuk pekerjaan teknis yang objektif, lalu menempatkan approval manusia hanya pada promosi dan perubahan berisiko tinggi.

Jika Anda ingin mulai sederhana, fokus dulu pada tiga hal: pre-commit lint/format, test bertahap yang stabil, dan satu approval gate yang jelas sebelum produksi. Setelah itu, tambahkan preview environment, checklist berbasis risiko, audit trail, dan metrik untuk memastikan proses benar-benar membantu, bukan sekadar terlihat rapi di atas kertas.