Saat Dua Orang Menjalankan Semuanya: Pipeline Sederhana yang Benar-Benar Berfungsi

Anda adalah salah satu dari dua orang yang membangun produk digital. Mungkin itu aplikasi web manajemen inventaris sederhana, atau layanan API untuk mitra bisnis. Tim Anda kecil, anggaran terbatas, dan tujuan Anda adalah memiliki sesuatu yang bisa digunakan dalam hitungan minggu, bukan bulan. Pada titik ini, pertanyaan pertama bukan tentang pipeline atau CI/CD. Pertanyaannya adalah: "Saat orang mulai menggunakan aplikasi ini, bagaimana cara saya mengirimkan versi baru tanpa harus login ke server setiap saat?"

Di startup kecil, proses manual terasa alami. Anda melakukan SCP file ke server, SSH untuk me-restart layanan, atau copy-paste query database. Itu berhasil untuk beberapa rilis pertama. Tapi setelah tiga atau empat kali, Anda mulai melihat celahnya. Anda lupa satu langkah. Anda salah menyalin file. Anda melewatkan migrasi. Dan jika Anda memiliki lebih dari satu lingkungan—misalnya, staging untuk pengujian dan production untuk pengguna nyata—Anda harus mengingat urutan yang tepat untuk masing-masing, berharap tidak ada yang terlewat.

Di sinilah pipeline sederhana masuk. Bukan sebagai proyek besar, tetapi sebagai alat yang menjalankan langkah yang sama setiap kali kode Anda berubah. Anda mulai dengan satu file konfigurasi di repositori Anda yang mendefinisikan tiga langkah: build, test, dan deploy. Build mengubah kode Anda menjadi artefak yang bisa dijalankan. Test menjalankan pemeriksaan otomatis—misalnya, apakah fitur baru merusak fitur lama. Deploy mengirimkan artefak ke server target.

Seperti Apa Pipeline Sederhana Itu

Untuk startup kecil, alatnya tidak perlu rumit. GitHub Actions, GitLab CI, atau CI bawaan dari penyedia cloud Anda semuanya baik-baik saja. Yang penting adalah pipeline berjalan secara otomatis saat Anda melakukan push ke branch tertentu. Misalnya, push ke main memicu build, test, dan deploy ke staging. Jika semuanya lolos, Anda deploy ke production dengan satu klik atau satu perintah.

Berikut contoh konkretnya. Bayangkan Anda memiliki aplikasi web Node.js yang dihosting di VPS kecil. File pipeline Anda mungkin terlihat seperti ini:

Berikut adalah gambaran visual dari pipeline:

Berikut adalah tampilan konfigurasi pipeline tersebut dalam praktik:

name: Simple Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build
      - run: |
          rsync -avz --delete dist/ user@staging-server:/var/www/app/
          ssh user@staging-server 'systemctl restart myapp'
flowchart TD A[Push ke main] --> B[Build: buat artefak] B --> C[Test: jalankan pemeriksaan otomatis] C --> D{Semua tes lolos?} D -- Ya --> E[Deploy ke staging] D -- Tidak --> F[Perbaiki kode dan push lagi] F --> A E --> G[Trigger manual untuk production] G --> H[Deploy ke production]
  • Saat push ke main: install dependensi, jalankan tes, build aplikasi, salin artefak build ke server staging, restart layanan.
  • Saat trigger manual atau tag: ulangi langkah yang sama tetapi deploy ke production.

Itu saja. Tidak ada Kubernetes, tidak ada orkestrasi kontainer, tidak ada gerbang persetujuan multi-tahap. Hanya tiga langkah yang berjalan konsisten setiap saat.

Kepemilikan Penuh Berarti Anda Menanggung Risikonya

Kepemilikan penuh berarti Anda dan rekan Anda memegang tanggung jawab penuh atas pipeline ini. Tidak ada tim DevOps terpisah. Tidak ada proses persetujuan yang panjang. Anda menulis pipeline, Anda menjalankannya, dan Anda memperbaikinya saat rusak. Kedengarannya seperti tekanan besar, tapi sebenarnya ini adalah keuntungan. Anda tahu persis bagaimana aplikasi Anda dikirimkan. Anda tahu apa yang bisa salah. Dan Anda tahu cara memperbaikinya karena Anda sendiri yang membangunnya.

Ketika sesuatu gagal—dan pasti akan gagal—Anda tidak menunggu tim lain merespons. Anda melihat log, mengidentifikasi langkah yang rusak, dan memperbaikinya. Pengalaman langsung ini sangat berharga. Ini mengajarkan Anda dasar-dasar pengiriman dengan cara yang tidak bisa ditiru oleh buku atau kursus mana pun.

Observabilitas Dasar Tanpa Obsesi Dashboard

Anda perlu tahu apakah pipeline Anda berhasil atau gagal, dan jika gagal, di langkah mana. Sebagian besar alat pipeline sudah menyediakan log dan notifikasi. Itu sudah cukup untuk saat ini. Anda tidak perlu tumpukan observabilitas lengkap dengan dashboard, alert, dan distributed tracing.

Tambahkan satu atau dua metrik sederhana ke aplikasi Anda sendiri. Lacak jumlah permintaan masuk, tingkat kesalahan, dan waktu respons rata-rata. Tiga angka ini memberi tahu Anda apakah versi baru berjalan normal setelah deployment. Jika tingkat kesalahan melonjak atau waktu respons melonjak, Anda tahu ada yang salah. Anda dapat memeriksa log pipeline untuk melihat apa yang berubah, dan roll back jika perlu.

Satu Hal yang Sering Dilupakan Tim Kecil

Dokumentasi. Bukan dokumentasi panjang dan detail yang tidak dibaca siapa pun. Hanya catatan singkat tentang cara kerja pipeline, apa yang harus dilakukan saat gagal, dan cara roll back ke versi sebelumnya. Tuliskan selagi masih segar di ingatan Anda. Catatan ini menjadi kritis saat Anda tidak bisa dihubungi—sedang di pesawat, sakit, atau liburan—dan terjadi masalah. Ini juga membantu saat tim Anda bertambah dan orang baru perlu memahami proses pengiriman.

File markdown sederhana di repositori Anda sudah cukup. Sertakan:

  • Branch yang memicu deployment ke setiap lingkungan
  • Perintah untuk melakukan roll back manual
  • Tempat menemukan log saat langkah gagal
  • Siapa yang harus dihubungi jika Anda berdua tidak tersedia

Kapan Pola Ini Berhenti Berfungsi

Pipeline sederhana ini tidak akan cocok selamanya. Seiring bertambahnya tim, aplikasi Anda menjadi lebih kompleks, dan basis pengguna Anda berkembang, Anda akan membutuhkan lebih banyak struktur. Anda mungkin perlu menjalankan tes secara paralel, langkah migrasi database, gerbang persetujuan untuk kepatuhan, atau strategi deployment seperti blue-green atau canary releases. Anda mungkin perlu memisahkan build, test, dan deploy ke dalam tahapan berbeda dengan tanggung jawab berbeda.

Namun untuk startup kecil yang perlu bergerak cepat, memulai dengan pipeline sederhana dan kepemilikan penuh adalah langkah yang tepat. Anda mempelajari dasar-dasar pengiriman tanpa terbebani alat yang rumit. Anda membangun fondasi yang bisa berkembang seiring perubahan kebutuhan. Dan Anda menghindari jebakan over-engineering sebelum Anda memiliki produk yang benar-benar digunakan orang.

Daftar Periksa Praktis untuk Pipeline Pertama Anda

  • Tentukan tiga langkah: build, test, deploy
  • Pilih satu alat CI (GitHub Actions, GitLab CI, atau bawaan penyedia cloud)
  • Atur pipeline untuk terpicu saat push ke main
  • Tambahkan langkah deploy manual untuk production
  • Catat jumlah permintaan, tingkat kesalahan, dan waktu respons di aplikasi Anda
  • Tulis dokumen satu halaman tentang cara roll back
  • Uji pipeline dengan sengaja merusaknya dan memperbaikinya

Intisari

Pipeline sederhana yang dibangun oleh orang-orang yang memiliki kode lebih baik daripada sistem kompleks yang dikelola oleh orang lain. Mulailah dari yang kecil, miliki prosesnya, dan biarkan fondasi tumbuh bersama produk Anda. Anda akan belajar lebih banyak tentang pengiriman dalam bulan pertama menjalankan pipeline daripada setahun hanya membaca tentangnya.