Workshop internal untuk standarkan tooling dan CI tim adalah cara praktis untuk mendapatkan manfaat seperti yang sering muncul dalam format Tech Week: tim berhenti sejenak dari pekerjaan harian, menyamakan standar kerja, lalu menghasilkan artefak yang langsung dipakai. Bedanya, sesi ini lebih kecil, lebih terarah, dan harus selesai dengan output konkret, bukan hanya diskusi.

Kalau masalah tim Anda adalah setup proyek yang berbeda-beda, aturan linting tidak konsisten, CI sering gagal karena hal sepele, onboarding lama, atau release checklist hanya ada di kepala beberapa orang, workshop 2–3 jam bisa menjadi titik awal yang realistis. Kuncinya bukan mengubah semua hal sekaligus, melainkan memilih pain point developer experience yang paling mahal dampaknya lalu mengubahnya menjadi standar bersama.

Konteks yang sering dibawa oleh tren seperti Tech Week adalah menyediakan waktu terfokus untuk perbaikan internal yang biasanya kalah prioritas oleh delivery. Artikel ini menerjemahkan semangat tersebut ke format workshop internal tim, bukan event recap.

Mengapa workshop internal ini efektif untuk developer experience

Banyak masalah tooling dan CI sebenarnya bukan masalah teknis yang rumit, tetapi masalah koordinasi. Satu engineer memakai formatter tertentu, engineer lain menjalankan test manual, pipeline CI memeriksa hal yang berbeda dari yang dicek lokal, dan reviewer PR menghabiskan waktu pada hal yang seharusnya bisa diotomatisasi.

Workshop singkat efektif karena memaksa tim menyepakati tiga hal sekaligus:

  • Definisi standar: apa yang wajib lolos sebelum kode dianggap siap direview atau dirilis.
  • Otomasi minimum: apa yang harus dijalankan lokal dan di CI.
  • Artefak bersama: file konfigurasi, template repo, script, dan checklist yang benar-benar tersimpan di repository.

Hasil terbaik dari sesi seperti ini bukan presentasi, melainkan perubahan yang bisa dilihat di git diff.

Output nyata yang sebaiknya wajib dihasilkan dalam 2–3 jam

Agar workshop tidak berubah menjadi forum curhat tanpa hasil, tetapkan deliverable sejak awal. Untuk topik standardisasi tooling dan CI, target realistisnya adalah lima hal berikut.

1. Template repository

Template repo menjadi baseline untuk proyek baru dan referensi untuk proyek lama. Minimal berisi struktur direktori, file konfigurasi standar, dan skrip dasar yang konsisten.

2. Aturan linting dan formatting

Tujuannya mengurangi perdebatan review yang berulang. Linting harus fokus pada aturan yang penting untuk kualitas, keterbacaan, dan pencegahan bug umum; jangan memasukkan terlalu banyak aturan yang belum siap ditegakkan.

3. Pre-commit hook

Hook lokal berguna untuk menangkap masalah cepat sebelum masuk ke PR. Namun hook jangan terlalu berat; jika terlalu lama, developer akan cenderung mem-bypass.

4. Workflow CI minimum

CI minimum biasanya mencakup install dependency, lint, unit test, dan validasi build. Ini cukup untuk menjaga integritas dasar tanpa membuat pipeline pertama menjadi kompleks.

5. Checklist release

Checklist release berguna untuk mencegah langkah manual yang sering terlupakan, seperti verifikasi migration, env variable baru, rollback plan, dan komunikasi perubahan.

Persiapan sebelum workshop

Persiapan menentukan apakah sesi 2–3 jam akan produktif atau habis untuk menyamakan konteks. Hindari datang ke ruangan lalu mulai dari pertanyaan “kita mau benahi apa?”.

Kumpulkan backlog masalah DX selama 1 minggu

Minta anggota tim mencatat hambatan nyata yang mereka alami. Gunakan sumber yang objektif bila ada: riwayat CI gagal, PR yang tertahan, issue onboarding, atau insiden release. Bentuk backlog yang baik bukan keluhan umum, tetapi masalah yang bisa dipecah menjadi tindakan.

Contoh backlog masalah developer experience:

  • Setiap service punya command test yang berbeda.
  • Lint hanya dijalankan sebagian orang, hasil review jadi tidak konsisten.
  • CI gagal karena perbedaan environment lokal dan runner.
  • Waktu onboarding lama karena setup dependency tidak terdokumentasi.
  • Release bergantung pada satu orang yang hafal urutannya.
  • PR kecil tertunda karena check yang tidak relevan atau flakey.
  • Tidak ada template untuk service baru, jadi struktur repo acak.

Pilih 1–2 pain point prioritas

Dalam workshop singkat, terlalu banyak target justru menurunkan peluang implementasi. Gunakan matriks sederhana: dampak tinggi, usaha rendah hingga sedang. Fokus pada masalah yang:

  • sering terjadi,
  • mengenai banyak orang,
  • bisa diotomatisasi,
  • dan hasilnya bisa langsung dipakai setelah sesi.

Contoh prioritas yang baik:

  • Menyamakan command setup, lint, test, dan build.
  • Menambahkan pre-commit hook untuk format dan lint ringan.
  • Membuat workflow CI standar untuk semua repository aplikasi.

Contoh target yang terlalu besar untuk 2–3 jam:

  • Merombak total arsitektur monorepo.
  • Mengganti seluruh toolchain build lintas tim.
  • Membangun platform internal lengkap dari nol.

Tentukan ruang lingkup teknis

Jika tim menangani banyak stack, putuskan apakah workshop akan fokus pada satu stack dulu atau membuat standar lintas stack yang hanya mencakup hal universal. Umumnya lebih aman memulai dari satu stack yang paling banyak dipakai, lalu mengekstrak pola.

Siapkan baseline data

Tanpa baseline, Anda sulit membuktikan workshop ini berguna. Ambil metrik sederhana sebelum perubahan:

  • Rata-rata lead time PR dari dibuka sampai merge.
  • Persentase build CI gagal pada percobaan pertama.
  • Rata-rata waktu onboarding sampai engineer bisa menjalankan test dan membuat PR pertama.
  • Jumlah komentar review yang membahas formatting atau hal mekanis.

Format workshop 2–3 jam yang tetap menghasilkan output

Berikut agenda yang realistis untuk satu sesi 150 menit.

Agenda contoh

  1. 15 menit - framing masalah
    Review backlog DX dan data baseline. Sepakati satu definisi sukses untuk sesi hari itu.
  2. 20 menit - pilih standar minimum
    Tentukan command standar, aturan lint dasar, apa yang masuk hook lokal, dan apa yang wajib di CI.
  3. 70 menit - pairing atau breakout implementation
    Bagi peran, implementasikan file konfigurasi, script, dan workflow CI langsung di repository template atau repo pilot.
  4. 25 menit - review hasil
    Jalankan demo: setup lokal, commit, push, CI berjalan, dan checklist release terlihat.
  5. 20 menit - rencana adopsi
    Tentukan repo mana yang diadopsi dulu, siapa owner-nya, dan kapan evaluasi metrik dilakukan.

Pembagian peran yang disarankan

  • Facilitator: menjaga ruang lingkup, waktu, dan keputusan.
  • Driver: menulis konfigurasi atau kode utama saat sesi.
  • Reviewer: mengecek trade-off, naming, dan kesesuaian dengan kebutuhan tim.
  • Recorder: mencatat keputusan, TODO, dan alasan di balik standar.
  • Owner adopsi: bertanggung jawab membawa hasil workshop ke repo pilot dan rollout berikutnya.

Untuk tim kecil, satu orang bisa memegang dua peran. Yang penting, ada satu pemilik keputusan dan satu pemilik tindak lanjut.

Contoh keputusan standar yang layak dibuat saat workshop

Definisikan command yang seragam

Terlepas dari bahasa pemrograman atau framework, usahakan setiap repo punya antarmuka command yang konsisten. Ini mengurangi beban kognitif saat pindah proyek.

make setup
make lint
make test
make build
make ci

Jika tidak memakai make, gunakan script setara di package manager atau shell script. Intinya bukan alatnya, tetapi konsistensinya.

Tentukan apa yang dijalankan lokal dan di CI

Aturan praktisnya:

  • Lokal / pre-commit: cepat, deterministik, fokus pada file yang berubah bila memungkinkan.
  • CI: sumber kebenaran utama, menjalankan validasi penuh yang mungkin terlalu berat untuk hook lokal.

Contoh pembagian yang sehat:

  • Pre-commit: format, lint ringan, cek file sensitif.
  • CI: install dependency bersih, lint penuh, unit test, build, dan validasi konfigurasi.

Kesalahan umum adalah memasukkan semua test ke pre-commit sehingga commit menjadi lambat. Akibatnya developer mencari cara mematikan hook.

Buat checklist release yang benar-benar dipakai

Checklist release harus spesifik pada langkah yang berisiko terlewat, bukan daftar generik yang terlalu panjang. Simpan di repository agar perubahan aplikasi dan perubahan proses tetap dekat.

# release-checklist.md

- Pastikan migration sudah direview dan punya rollback plan.
- Verifikasi env var baru sudah didaftarkan.
- Pastikan changelog atau release note terisi bila diperlukan.
- Confirm CI hijau pada commit yang akan dirilis.
- Validasi langkah deploy dan owner on-call.
- Siapkan prosedur rollback jika deployment gagal.

Contoh struktur repository hasil workshop

Struktur berikut bisa dipakai sebagai titik awal template repo. Sesuaikan dengan stack tim, tetapi pertahankan prinsip: command jelas, konfigurasi terpusat, dokumentasi setup dan release mudah ditemukan.

repo-template/
├─ .ci/
│  └─ pipeline.yml
├─ .githooks/
│  └─ pre-commit
├─ docs/
│  ├─ onboarding.md
│  └─ release-checklist.md
├─ scripts/
│  ├─ setup.sh
│  ├─ lint.sh
│  ├─ test.sh
│  └─ ci.sh
├─ src/
├─ tests/
├─ .editorconfig
├─ .gitignore
├─ Makefile
├─ README.md
└─ lint-config

Beberapa catatan penting:

  • README.md sebaiknya berisi quick start yang benar-benar diuji.
  • docs/onboarding.md berguna untuk hal yang lebih detail dari README.
  • scripts/ membantu membungkus perbedaan command internal sehingga CI dan developer lokal memanggil entry point yang sama.
  • .editorconfig adalah standar murah dan lintas editor untuk whitespace, indentasi, dan newline.

Contoh workflow CI minimum

Karena tool CI berbeda-beda, contoh di bawah sengaja generik. Fokusnya adalah urutan validasi dan alasan di baliknya.

steps:
  - checkout
  - setup runtime and dependencies
  - restore cache if available
  - run: ./scripts/lint.sh
  - run: ./scripts/test.sh
  - run: ./scripts/build.sh

Mengapa pendekatan ini bekerja:

  • Entry point tunggal: CI memanggil script yang sama dengan developer lokal, sehingga perilaku lebih konsisten.
  • Pemisahan concern: lint, test, dan build punya langkah terpisah, memudahkan debugging saat gagal.
  • Mudah dipindahkan: saat berganti vendor CI, logika inti tetap ada di repository, bukan terkunci di YAML platform.

Kalau ingin menambah kompleksitas, lakukan setelah pipeline dasar stabil. Misalnya matrix test, parallel job, atau deployment gate. Jangan menjadikan semua itu sebagai syarat adopsi awal.

Aturan memilih pain point prioritas

Dalam workshop internal untuk standarkan tooling dan CI tim, pemilihan prioritas lebih penting daripada jumlah ide yang dikumpulkan. Gunakan kerangka penilaian sederhana berikut.

Skor prioritas 1–5 untuk tiap kriteria

  • Frekuensi: seberapa sering masalah terjadi.
  • Dampak: seberapa besar pengaruhnya terhadap delivery atau kualitas.
  • Cakupan: berapa banyak engineer atau repo yang terdampak.
  • Otomasi: seberapa mudah masalah ini diubah menjadi check otomatis.
  • Biaya adopsi: seberapa berat perubahan untuk repo yang sudah berjalan.

Pilih item dengan kombinasi frekuensi, dampak, dan cakupan tinggi, tetapi biaya adopsi masih masuk akal. Misalnya, menyamakan command dan lint dasar biasanya menang dibanding refactor workflow deployment yang sangat spesifik.

Pertanyaan filter sebelum mengeksekusi

  • Apakah hasilnya bisa disimpan sebagai file atau script di repo?
  • Apakah orang baru akan merasakan manfaatnya dalam minggu pertama?
  • Apakah reviewer PR akan mendapat pengurangan pekerjaan manual?
  • Apakah CI akan menjadi lebih stabil atau lebih mudah dipahami?

Adopsi bertahap agar tidak mengganggu delivery

Masalah umum setelah workshop adalah hasilnya bagus di satu repo, tetapi tidak pernah diadopsi luas karena tim takut mengganggu pekerjaan aktif. Solusinya adalah rollout bertahap dengan batas risiko yang jelas.

Tahap 1: pilot pada satu repository

Pilih repo yang aktif tetapi tidak paling kritis. Terapkan template, lint minimum, hook lokal, dan CI dasar. Catat friction yang muncul: dependensi sulit, test tidak deterministik, atau script terlalu spesifik.

Tahap 2: ekstrak pola ke template bersama

Setelah pilot stabil, pindahkan hal yang generik ke template repo atau starter kit internal. Hindari menyalin konfigurasi mentah tanpa dokumentasi alasan.

Tahap 3: adopsi ke repo lain saat ada perubahan alami

Jangan membuka belasan PR migrasi sekaligus jika tim sedang mengejar deadline. Lebih aman memasukkan standardisasi saat repo sedang disentuh untuk fitur, perbaikan test, atau pemeliharaan rutin.

Tahap 4: jadikan standar sebagai default

Untuk repo baru, gunakan template langsung. Untuk repo lama, buat checklist migrasi singkat. Pada titik ini, keberhasilan diukur dari semakin sedikit pengecualian, bukan dari semua repo langsung identik.

Adopsi bertahap lebih lambat, tetapi biasanya lebih tahan lama. Standardisasi yang dipaksakan terlalu cepat sering berakhir dengan banyak pengecualian dan bypass.

Metrik hasil yang layak dipantau

Perbaikan developer experience harus terlihat dalam alur kerja, bukan hanya dalam opini. Berikut metrik yang cukup praktis untuk tim engineering.

Lead time PR

Ukur waktu dari PR dibuka sampai merge. Standardisasi tooling biasanya membantu dengan mengurangi komentar mekanis, mengurangi bolak-balik karena check terlambat, dan membuat status kualitas lebih cepat terlihat.

Tingkat gagal build

Lihat berapa banyak build yang gagal pada percobaan pertama, lalu kategorikan penyebabnya. Jika kegagalan didominasi lint, format, atau setup yang sebenarnya bisa dicegah lokal, hook dan command standar akan membantu.

Waktu onboarding

Ukur waktu sampai engineer baru bisa:

  • menjalankan aplikasi atau service secara lokal,
  • menjalankan test,
  • dan membuka PR pertama yang lolos CI.

Jika workshop berhasil, dokumentasi dan template repo akan memangkas ketergantungan pada bantuan sinkron dari engineer lain.

Rasio komentar review mekanis

Sampel beberapa PR dan lihat apakah reviewer masih sering membahas format, struktur command, atau langkah setup yang berulang. Semakin sedikit komentar mekanis, semakin banyak waktu review untuk logika bisnis, desain API, dan risiko sistem.

Kesalahan umum dan cara menghindarinya

Terlalu banyak aturan di awal

Semakin banyak aturan, semakin sulit adopsinya. Mulai dari standar yang memberi manfaat besar dengan friction rendah.

Hook lokal terlalu lambat

Jika commit memerlukan waktu terlalu lama, developer akan frustrasi. Simpan validasi berat di CI dan buat hook fokus pada pemeriksaan cepat.

CI berbeda dengan workflow lokal

Ini salah satu sumber kebingungan terbesar. Gunakan script yang sama sebanyak mungkin agar “lolos di laptop” dan “lolos di CI” punya definisi yang dekat.

Tidak ada owner pasca-workshop

Artefak tanpa owner biasanya berhenti di satu PR. Tetapkan siapa yang menjaga template, siapa yang menerima usulan perubahan standar, dan kapan standar ditinjau ulang.

Memaksa semua repo identik

Beberapa repo memang punya kebutuhan berbeda. Bedakan antara baseline wajib dan ekstensi opsional. Misalnya, command dasar dan release checklist bisa wajib, sedangkan langkah build tertentu bisa spesifik per layanan.

Checklist persiapan singkat untuk memulai minggu ini

  1. Kumpulkan 5–10 masalah DX nyata dari tim.
  2. Pilih 1–2 pain point dengan dampak tertinggi.
  3. Tentukan deliverable workshop: template repo, lint rules, pre-commit, CI, release checklist.
  4. Ambil baseline metrik: lead time PR, gagal build, onboarding.
  5. Jadwalkan sesi 2–3 jam dengan facilitator dan owner adopsi.
  6. Implementasikan langsung pada satu repo pilot atau template internal.
  7. Evaluasi 2–4 minggu kemudian berdasarkan metrik dan feedback tim.

Penutup

Workshop internal untuk standarkan tooling dan CI tim bekerja baik ketika diposisikan sebagai sesi implementasi, bukan sesi opini. Dengan ruang lingkup yang sempit tetapi konkret, tim bisa meniru manfaat Tech Week: menyediakan waktu terfokus untuk memperbaiki cara kerja developer, mengurangi friksi berulang, dan menghasilkan standar yang hidup di repository.

Mulailah dari hal kecil yang dampaknya besar: command yang seragam, lint yang disepakati, hook lokal yang ringan, CI minimum yang konsisten, dan checklist release yang jelas. Jika hasilnya diadopsi bertahap dan diukur dengan metrik yang tepat, workshop singkat seperti ini bisa memberi perbaikan DX yang terasa tanpa mengorbankan delivery.