Workflow WIP untuk tim Rust adalah cara kerja yang memecah satu fitur besar menjadi beberapa PR kecil, masing-masing cukup jelas, cukup aman, dan tetap bisa direview tanpa menunggu fitur selesai sepenuhnya. Tujuannya bukan menambah formalitas, tetapi mengurangi antrean review, menurunkan risiko merge conflict, dan menjaga branch utama tetap sehat.

Dalam praktik Rust, pendekatan ini sangat cocok karena perubahan besar sering menyentuh banyak area sekaligus: tipe data, trait, module boundary, error handling, test, sampai integrasi CI. Jika semua digabung dalam satu PR besar, reviewer sulit fokus, feedback datang terlambat, dan perbaikan kecil sering tertahan. Dengan WIP yang benar, tim bisa merge perubahan bertahap tanpa membuka fitur setengah jadi ke pengguna.

Mengapa PR kecil lebih efektif untuk tim Rust

PR kecil bukan sekadar lebih cepat dibaca. Di Rust, ukuran PR sangat memengaruhi kualitas review karena banyak perubahan punya dampak struktural. Refactor signature fungsi, penggantian trait bound, atau perubahan ownership model bisa terlihat sederhana tetapi menyebar ke banyak file.

  • Feedback dini: desain API internal, bentuk type, atau pemisahan module bisa dikoreksi sebelum terlalu banyak kode dibangun di atas fondasi yang salah.
  • Merge conflict lebih rendah: branch hidup lebih singkat dan perubahan lebih sempit.
  • Review lebih tajam: reviewer bisa fokus pada satu jenis perubahan, misalnya refactor data model, bukan sekaligus membaca logic bisnis, test, dan wiring CI.
  • Release lebih stabil: perubahan yang sudah aman bisa digabung lebih awal, sementara perilaku baru dikunci dengan feature flag.
  • Rollback lebih mudah: commit atau PR kecil lebih gampang dibatalkan daripada satu PR besar yang mencampur banyak hal.

Masalah paling umum bukan pada niat, tetapi pada cara memecah kerja. Banyak tim mencoba membuat PR kecil, namun tiap PR ternyata tidak bisa di-merge karena aplikasi belum kompilasi, test rusak, atau perubahan antar-PR saling bergantung tanpa pagar pengaman. Di sinilah workflow WIP perlu dirancang dengan disiplin teknis.

Prinsip dasar workflow WIP yang bisa di-merge

1. Pisahkan perubahan struktural dari perubahan perilaku

Langkah awal yang paling aman biasanya adalah perubahan yang tidak mengubah perilaku: memindahkan module, menambah trait, menyiapkan type baru, atau membuat adapter. Setelah itu baru masukkan logic baru sedikit demi sedikit.

Contoh urutan yang baik untuk fitur besar:

  1. Tambahkan type dan interface baru tanpa dipakai jalur utama.
  2. Tambahkan adapter atau lapisan kompatibilitas.
  3. Pindahkan call site sedikit demi sedikit.
  4. Aktifkan perilaku baru lewat feature flag atau konfigurasi internal.
  5. Hapus kode lama setelah migrasi selesai.

Urutan ini bekerja karena setiap langkah tetap bisa dibangun, dites, dan direview secara terpisah.

2. Setiap PR harus berada dalam keadaan valid

Valid berarti setidaknya:

  • kode bisa di-format,
  • lulus lint minimum,
  • kompilasi berhasil,
  • test yang relevan lulus,
  • tidak mengekspos perilaku setengah jadi ke production tanpa pengaman.

Kalau sebuah PR membutuhkan “tolong abaikan dulu, nanti PR berikutnya memperbaiki”, itu tanda pemecahan kerjanya belum tepat.

3. Gunakan feature flag untuk memisahkan merge dari release

Ini salah satu kunci terpenting. Banyak tim takut merge PR kecil karena fitur belum selesai. Solusinya bukan menahan branch terlalu lama, tetapi memisahkan penggabungan kode dari aktivasi fitur. Dalam Rust, feature flag atau gate berbasis konfigurasi sangat membantu.

Untuk library, Anda bisa memakai feature Cargo. Untuk aplikasi, sering kali lebih aman memakai flag runtime atau konfigurasi internal agar perilaku bisa dinyalakan dengan sadar, bukan otomatis saat build tertentu.

Contoh cara memecah fitur besar menjadi PR kecil

Misalkan tim ingin menambahkan pipeline validasi baru untuk pemrosesan order. Jangan langsung membuat satu PR yang berisi model, validator, wiring handler, migration, dan test integrasi penuh. Pecah seperti ini:

PR 1: Refactor fondasi tanpa ubah perilaku

  • Pisahkan module order menjadi order/domain dan order/service.
  • Tambahkan trait OrderValidator.
  • Implementasi default masih memanggil validator lama.

PR 2: Tambah implementasi validator baru di belakang flag

  • Buat NewOrderValidator.
  • Belum dipakai di jalur utama.
  • Tambah unit test khusus validator baru.

PR 3: Wiring seleksi validator

  • Tambahkan mekanisme pemilihan validator berdasarkan config atau feature gate internal.
  • Default tetap validator lama.

PR 4: Aktifkan di lingkungan non-production

  • Tambah test integrasi untuk alur baru.
  • Aktifkan hanya di environment uji atau canary.

PR 5: Bersihkan kode lama

  • Setelah perilaku baru stabil, hapus validator lama dan kompatibilitas sementara.

Setiap PR di atas punya nilai review yang jelas. Reviewer bisa fokus: struktur, implementasi validator, wiring, rollout, lalu cleanup.

Struktur branch yang sederhana dan tahan lama

Workflow WIP tidak membutuhkan model branching yang rumit. Untuk banyak tim Rust, struktur berikut sudah cukup:

  • main: selalu hijau, siap dijadikan basis release.
  • feat/nama-fitur: branch kerja utama jika memang butuh rangkaian perubahan lokal.
  • feat/nama-fitur-pr-01-setup, feat/nama-fitur-pr-02-validator: branch turunan untuk PR kecil jika perlu.

Namun dalam banyak kasus, branch terpisah per PR lebih mudah daripada satu branch besar yang terus ditumpuk. Jika memakai stack PR, pastikan tim paham dependensinya dan tahu kapan harus melakukan rebase.

Contoh penamaan branch

main
feat/order-validation-pr-01-foundation
feat/order-validation-pr-02-new-validator
feat/order-validation-pr-03-wiring
fix/clippy-order-service
refactor/order-module-split

Prinsipnya: nama branch harus memberi tahu reviewer konteks perubahan, bukan hanya nomor tiket.

Kapan pakai branch biasa

Gunakan branch biasa bila perubahan masih eksploratif dan belum layak dibuka ke reviewer. Misalnya, Anda masih mencoba desain API, belum tahu bentuk final type, atau belum bisa memastikan kompilasi. Branch ini sifatnya pribadi dan sebaiknya berumur pendek.

Kapan pakai draft PR

Gunakan draft PR ketika:

  • arah implementasi sudah cukup jelas,
  • Anda ingin feedback dini pada desain atau pembagian langkah,
  • PR belum siap merge tetapi sudah cukup stabil untuk dibaca,
  • Anda ingin CI berjalan dan diskusi tercatat sejak awal.

Jangan pakai draft PR sebagai tempat menumpuk pekerjaan selama berminggu-minggu tanpa batas yang jelas. Draft PR idealnya tetap punya tujuan sempit: meminta masukan desain, menampilkan urutan kerja, atau memvalidasi pendekatan teknis.

Aturan praktis: kalau reviewer sudah bisa memberi umpan balik yang bermakna tanpa harus menebak-nebak konteks, bukalah draft PR. Kalau kode masih terlalu cair dan bahkan deskripsi masalahnya belum stabil, simpan dulu di branch biasa.

Konvensi commit yang membantu review

Commit dalam workflow WIP harus membantu reviewer memahami evolusi perubahan, bukan sekadar menjadi snapshot acak. Tidak harus terlalu formal, tetapi sebaiknya konsisten.

Prinsip commit untuk PR kecil

  • Satu commit untuk satu ide teknis utama.
  • Hindari mencampur refactor, formatting massal, dan perubahan perilaku dalam commit yang sama.
  • Tulis pesan commit yang menjelaskan niat perubahan.
  • Squash boleh dilakukan sebelum merge, tetapi commit lokal yang rapi tetap memudahkan review selama PR berjalan.

Contoh format commit

refactor(order): split validation logic from service
feat(order): add new validator behind internal flag
test(order): cover invalid shipping address cases
chore(ci): run clippy on workspace for pull requests
fix(order): preserve legacy validation fallback

Format seperti ini membantu karena reviewer bisa menebak isi perubahan sebelum membuka diff. Jika tim tidak ingin memakai gaya tertentu, minimal bedakan commit refactor, feature, test, dan CI.

Feature flag di proyek Rust: kapan Cargo feature, kapan runtime flag

Tim Rust sering langsung berpikir ke [features] di Cargo.toml. Itu berguna, tetapi tidak selalu tepat untuk workflow WIP.

Cargo feature cocok untuk:

  • library yang memang menawarkan API opsional,
  • integrasi dependensi opsional,
  • kompilasi kode tertentu hanya pada build tertentu.

Runtime flag atau config internal lebih cocok untuk:

  • aplikasi server,
  • rollout bertahap,
  • mengaktifkan perilaku baru tanpa mengubah cara build artefak utama.

Untuk aplikasi backend Rust, mengunci fitur setengah jadi di balik flag runtime sering lebih stabil karena artefak yang diuji dan yang dirilis tetap konsisten. Anda tidak ingin jalur release berubah hanya karena kombinasi feature Cargo berbeda.

Contoh feature Cargo sederhana

[features]
default = []
new-order-validation = []
#[cfg(feature = "new-order-validation")]
pub mod new_validator;

Contoh ini cocok untuk modul opsional, tetapi jika fitur harus diuji dalam jalur produksi yang sama, pertimbangkan gate berbasis konfigurasi runtime.

Contoh gate runtime sederhana

pub struct ValidationConfig {
    pub new_validator_enabled: bool,
}

pub fn validate_order(cfg: &ValidationConfig, order: &Order) -> Result<(), ValidationError> {
    if cfg.new_validator_enabled {
        new_validate(order)
    } else {
        legacy_validate(order)
    }
}

Pendekatan ini memudahkan rollout bertahap dan test A/B internal tanpa memecah artefak build.

CI minimum untuk PR WIP: cukup ketat, tetap cepat

PR WIP butuh CI, tetapi CI yang terlalu berat bisa membuat tim kembali menumpuk perubahan agar “sekali jalan”. Targetnya adalah fast feedback. Jalankan pemeriksaan minimum yang punya nilai tinggi dan waktu relatif singkat.

Baseline CI untuk PR WIP Rust

  • cargo fmt --check untuk menjaga diff tetap rapi.
  • cargo clippy pada crate atau workspace yang relevan.
  • cargo test untuk unit test cepat.
  • Build debug untuk memastikan integrasi dasar tidak rusak.

Untuk suite yang mahal seperti integration test penuh, database end-to-end, atau benchmark, jalankan di tahap terpisah: nightly, merge queue, atau hanya untuk PR yang sudah siap merge.

Contoh urutan perintah lokal dan CI

cargo fmt --all --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace --lib --bins
cargo test --workspace --tests

Anda tidak harus selalu menjalankan semua target di setiap PR kecil jika monorepo besar. Yang penting, aturan tim jelas: PR kecil wajib lulus baseline cepat, sedangkan pengujian mahal dijalankan di gerbang berikutnya.

Mengapa lint dan test harus tetap cepat

Kalau CI PR memakan waktu lama, developer cenderung menunggu sampai perubahan menumpuk sebelum push. Akibatnya tujuan workflow WIP gagal. Lebih baik punya baseline cepat dan andal daripada pipeline sangat lengkap tetapi lambat hingga menghambat iterasi.

Tips praktis menjaga CI cepat

  • Prioritaskan unit test yang deterministik dan tidak bergantung jaringan.
  • Hindari setup service eksternal untuk tiap PR jika tidak benar-benar perlu.
  • Batasi scope workspace yang dicek jika struktur repo mendukung.
  • Jangan jadikan warning clippy sebagai diskusi panjang per PR; sepakati subset yang wajib atau langsung konsisten dengan -D warnings jika tim siap.

Aturan lint, format, dan test bertahap yang realistis

Workflow WIP berhasil jika ada definisi jelas tentang “cukup bersih untuk direview” dan “cukup aman untuk di-merge”. Untuk proyek Rust, aturan berikut umumnya praktis:

Level 1: wajib untuk semua PR, termasuk draft yang meminta feedback teknis

  • format lulus,
  • kompilasi lulus pada target utama,
  • tidak ada warning kritis yang sengaja diabaikan,
  • test unit yang relevan lulus.

Level 2: wajib sebelum siap merge

  • clippy pada cakupan yang disepakati,
  • integration test penting,
  • dokumentasi atau changelog internal jika perubahan menyentuh API,
  • flag default aman: fitur baru tidak aktif tanpa keputusan eksplisit.

Level 3: pasca-merge atau pipeline terjadwal

  • test mahal lintas service,
  • uji kompatibilitas lebih luas,
  • benchmark, fuzzing, atau audit tambahan.

Pemisahan level seperti ini menghindari dua ekstrem: terlalu longgar sampai branch utama rusak, atau terlalu ketat sampai semua orang takut membuka PR kecil.

Template PR WIP untuk proyek Rust

Template berikut membantu reviewer memahami status PR dengan cepat.

## Ringkasan
PR ini adalah bagian dari workflow WIP untuk fitur: order validation baru.
Tujuan PR ini: menyiapkan trait dan struktur module tanpa mengubah perilaku default.

## Jenis perubahan
- [x] Refactor tanpa perubahan perilaku
- [ ] Fitur baru di balik flag
- [ ] Perubahan perilaku default
- [ ] Cleanup / hapus kompatibilitas lama

## Status
- [x] Bisa dikompilasi
- [x] Siap direview
- [ ] Siap merge
- [x] Masih bagian dari rangkaian PR

## PR terkait
- Sebelumnya: none
- Berikutnya: wiring validator baru
- Issue/tiket: ABC-123

## Feature flag / gating
- Default behavior tetap validator lama
- Kode baru belum aktif di jalur utama

## Checklist lokal
- [x] cargo fmt --all --check
- [x] cargo clippy --workspace --all-targets -- -D warnings
- [x] cargo test --workspace --lib --bins
- [ ] cargo test --workspace --tests

## Fokus review
Mohon fokus pada:
1. boundary module baru
2. nama trait `OrderValidator`
3. apakah adapter kompatibilitas cukup jelas

## Catatan
- Saya sengaja belum menghubungkan implementasi baru ke handler.
- Aktivasi fitur akan datang di PR berikutnya agar diff tetap kecil.

Template ini menekan kebingungan reviewer. Mereka langsung tahu apakah PR dimaksudkan untuk merge, apa fokus review-nya, dan apa yang sengaja belum dilakukan.

Contoh alur kerja harian yang bisa diadopsi tim

  1. Pilih fitur besar yang berisiko menjadi PR besar.
  2. Tulis rencana pecahan PR dalam 3-6 langkah maksimal.
  3. Buat PR pertama yang hanya menyiapkan struktur atau kompatibilitas.
  4. Jika perlu feedback dini, buka sebagai draft PR dengan fokus review spesifik.
  5. Pastikan tiap PR lulus CI minimum dan aman digabung.
  6. Gunakan feature flag atau gate runtime untuk menahan perilaku baru.
  7. Merge bertahap ke main, jangan tunggu semua pekerjaan selesai.
  8. Setelah rollout aman, buat PR cleanup untuk menghapus kode sementara.

Dengan alur ini, branch utama tetap bergerak, reviewer tidak dibebani satu diff besar, dan releasability terjaga.

Anti-pattern umum dalam workflow WIP

1. Draft PR raksasa yang hidup terlalu lama

Draft PR bukan tempat menyimpan semua pekerjaan sampai selesai. Kalau diff sudah sangat besar, reviewer tetap kesulitan walaupun statusnya draft.

2. PR kecil tetapi tidak independen

Misalnya PR 1 sengaja merusak build karena PR 2 akan memperbaiki. Ini membuat branch utama tidak bisa dipercaya dan menghilangkan manfaat WIP.

3. Feature flag tidak benar-benar menahan perilaku baru

Kadang kode disebut “di balik flag”, tetapi side effect-nya sudah aktif, migration sudah memaksa jalur baru, atau default config justru menyalakan fitur. Verifikasi jalur default tetap aman.

4. Menumpuk refactor dan fitur dalam satu langkah

Refactor besar plus logic baru sangat sulit direview. Pisahkan dulu perubahan mekanis dari perubahan perilaku.

5. CI PR terlalu berat

Kalau tiap PR kecil harus menunggu test yang mahal dan lama, tim akan terdorong membuat PR lebih jarang dan lebih besar.

6. Terlalu banyak dependensi antar-PR

Stack PR memang berguna, tetapi jika rantainya terlalu panjang, satu perubahan kecil di bawah bisa memaksa rebase berulang di semua PR atasnya. Usahakan tiap langkah tetap bernilai sendiri dan bisa digabung secepat mungkin.

Debugging dan evaluasi bila adopsi WIP terasa gagal

Jika tim merasa workflow WIP tidak membantu, biasanya masalahnya ada di salah satu titik berikut:

  • PR masih terlalu besar: cek apakah satu PR mencampur struktur, logic, dan test integrasi sekaligus.
  • Reviewer lambat memberi feedback: cek apakah deskripsi PR tidak jelas atau fokus review tidak disebutkan.
  • Terlalu banyak rebase: cek apakah tim terlalu bergantung pada stack branch yang panjang.
  • Main sering rusak: cek apakah aturan minimum CI terlalu longgar.
  • Fitur setengah jadi bocor ke pengguna: audit kembali gating dan default config.

Ukur dampaknya secara sederhana: waktu dari PR dibuka sampai review pertama, waktu sampai merge, jumlah conflict saat rebase, dan seberapa sering PR besar tertunda karena reviewer kewalahan. Anda tidak perlu metrik rumit untuk melihat apakah pola kerja membaik.

Checklist adopsi untuk tim Rust

  • Sepakati definisi PR kecil: satu tujuan teknis utama, bukan satu tiket penuh.
  • Tentukan baseline CI: minimal cargo fmt, clippy, dan test cepat.
  • Pilih strategi gating: Cargo feature untuk library, runtime flag untuk aplikasi bila perlu rollout aman.
  • Gunakan template PR WIP: status, fokus review, PR terkait, dan checklist lokal.
  • Latih pemecahan kerja: pisahkan fondasi, wiring, aktivasi, dan cleanup.
  • Batasi umur draft PR: jika membesar, pecah ulang.
  • Jaga branch utama selalu sehat: tidak ada PR yang merge dengan build rusak.
  • Review berdasarkan fokus: reviewer tahu apa yang harus diperiksa pada tiap langkah.
  • Jadwalkan cleanup: feature flag sementara dan adapter kompatibilitas harus dihapus setelah migrasi selesai.

Penutup

Workflow WIP untuk tim Rust bukan soal membuka PR lebih sering tanpa arah, tetapi soal membuat setiap langkah kecil, valid, dan bisa direview dengan jelas. Jika pekerjaan besar dipecah menjadi rangkaian PR kecil yang aman digabung, tim akan mendapat feedback lebih dini, risiko merge conflict turun, dan release menjadi lebih stabil karena merge tidak lagi menunggu satu “PR final” yang terlalu besar.

Mulailah dari satu fitur besar berikutnya. Pecah menjadi beberapa langkah yang masing-masing tetap buildable, gunakan draft PR saat butuh umpan balik dini, lindungi perilaku baru dengan feature flag atau config, dan jaga CI tetap cepat. Biasanya, perubahan terbesar bukan pada tooling, melainkan pada disiplin memisahkan perubahan struktural dari perubahan perilaku.