Workflow Development

Perjalanan panjang kita dengan database kini tuntas: PostgreSQL, MySQL, MariaDB, dan Redis berjalan dari satu perintah, data bertahan melewati kematian container, skema lahir dari inisialisasi yang terkendali, cadangan bisa dibuat dan dipulihkan, dan perubahan versi image maupun skema berjalan lewat migrasi yang tercatat — dan proyek katalog Budi tetap menjadi kendaraan seluruhnya. Sisi infrastruktur dari pekerjaan kita dengan demikian sudah berdiri di atas container, dan stack development yang dirakit pada Chapter Local Development Stack membuktikan bahwa satu rangkaian perintah docker compose cukup untuk menyala lengkap di laptop siapa pun. Namun jika kita menghitung detik kerja sehari penuh, yang paling sering kita sentuh justru bukan database, melainkan editor: menulis kode, menjalankannya, mengamati hasil, memperbaiki, lalu mencommit. Section ini membelokkan lensa Docker ke rutinitas tersebut — bagaimana siklus edit-uji-commit bekerja ketika aplikasi dan toolchain-nya hidup di dalam container — dan chapter pembuka ini memilih bentuk workflow itu lebih dulu, sebelum kita mengetik satu perintah teknis pun.

Satu Hari Tanpa Container dan Satu Hari dengan Container #

Untuk merasakan bedanya, Budi cukup mengingat dua skenario onboarding. Skenario pertama adalah hari-hari sebelum Docker: ketika rekan baru bergabung di proyek berbasis Node.js dan PostgreSQL, hari pertamanya habis untuk memasang Node versi yang “sepertinya sama”, meladeni galat dependensi yang muncul di laptopnya saja, dan berunding dengan manajer paket soal versi PostgreSQL. Hari keduanya baru produktif — dan itu bila beruntung, karena satu environment variable yang terlewat masih sanggup memakan setengah hari. Skenario kedua adalah hari pertama Siti pada Chapter Local Development Stack: git clone, menyalin .env.example menjadi .env, lalu docker compose up -d — dan stack lengkap dengan proxy, database, cache, sampai alat administrasinya menyala dalam hitungan menit.

Mari kita telaah baris-baris yang paling menentukan pada tabel di atas. Pertama, baris konsistensi adalah kelanjutan langsung dari masalah works on my machine yang kita bedah pada Chapter Masalah yang Diselesaikan Docker: image membekukan toolchain dan dependensi sehingga dua laptop tidak lagi punya kesempatan berbeda. Kedua, baris onboarding menunjukkan bahwa nilainya bukan sekadar kenyamanan — setiap hari yang dihemat dari ritual pemasangan adalah hari yang langsung menjadi kontribusi kode. Ketiga, baris membereskan bekas mengubah psikologi bereksperimen: mencoba skema baru, gagal, lalu memusnahkannya tanpa bekas menjadi ritual yang murah, sehingga kita lebih berani belajar.

Siklus Edit Uji dan Commit #

Di dunia container, hari kerja berputar dalam satu lingkaran kecil yang sama setiap jamnya: menyunting berkas, memastikan perubahan sampai ke container, memverifikasi hasil, lalu mencommit bila lolos. Seluruh chapter di section ini sebenarnya adalah alat untuk memangkas gesekan di tiap sisi lingkaran itu.

Mari kita telaah lingkaran tersebut tahap demi tahap:

1. Suntingan dimulai dari editor di host — kita tidak pindah editor; editor, linter bawaan editor, dan git tetap hidup di laptop seperti biasa.
2. Perubahan berpindah ke container tanpa build — mekanismenya bind mount atau aksi sync milik develop.watch; keduanya akan kita pilihkan di bagian bawah chapter ini.
3. Aplikasi memuat ulang kode — container tidak otomatis menjalankan kode baru; dibutuhkan watch mode seperti nodemon atau aturan restart, materi Chapter Hot Reload.
4. Verifikasi adalah gerbang commit — bisa seringan curl ke endpoint, mengikuti log dengan docker compose logs -f, atau seberat rangkaian npm test dalam container — pola lengkapnya menanti Chapter Menjalankan Test di Container.
5. Commit tetap terjadi di host — git tidak pernah pindah ke container; berkas yang sama yang dilihat container adalah berkas yang dicommit, dan di sinilah konsistensi lingkungan terbayar: kode yang lolos uji di laptop kita akan berperilaku sama di laptop rekan.

Tiga Pendekatan Menjalankan Kode saat Development #

Ada lebih dari satu cara memakai Docker untuk rutinitas harian, dan ketiganya kita jumpai di proyek nyata. Pilihan di antaranya bukan perkara benar-salah, melainkan perkiraan timbangan antara kenyamanan editor, konsistensi lingkungan, dan kinerja mesin.

Toolchain di Host Database di Container #

Bentuk paling sederhana: Node.js tetap terpasang di laptop, dan container hanya menjalankan hal-hal yang menyusahkan bila dipasang native — database yang paling sering. compose.yaml menjadi pendek karena service aplikasinya tidak ada:

services:
  db:
    image: postgres:18-alpine
    environment:
      POSTGRES_USER: katalog
      POSTGRES_PASSWORD: rahasia123
      POSTGRES_DB: katalog
    ports:
      - "5432:5432"
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Aplikasi kemudian berjalan sebagai proses biasa di host, mengarah ke localhost:

$ DATABASE_URL=postgres://katalog:rahasia123@localhost:5432/katalog node src/server.js

Mari kita telaah dua keputusan pada bentuk ini: ports: "5432:5432" wajib ada karena proses di host menembus keluar network container — kebalikan dari pola service-ke-service yang memakai DNS internal pada Chapter Port dan Network; dan DATABASE_URL menunjuk localhost karena dari sudut pandang proses host, database hanyalah server di mesin yang sama. Kelebihannya nyata: editor, debugger, dan autocomplete bekerja native tanpa perantara, dan kinerja berkas tidak melintasi batas container. Kelemahannya juga nyata: versi Node tetap bergantung instalasi tiap mesin, sehingga “works on my machine” hanya setengah terselesaikan.

Seluruhnya di Dalam Container #

Bentuk kedua memindahkan seluruh toolchain ke container: kode disunting di host, tetapi Node.js, npm, dan dependensinya hanya hidup di dalam container yang menjalankan aplikasi. Jembatan di antara keduanya adalah bind mount source code — mekanisme dari Chapter Bind Mount yang dipakai khusus untuk development. Inilah jalur yang kita bangun sepanjang section ini: Chapter Bind Mount Source Code menyiapkan mount-nya, Chapter Hot Reload menghidupkan siklus muat-ulangnya, dan dua chapter setelahnya merapikan image serta alat debugnya. Kekuatannya adalah konsistensi penuh — rekan dengan Windows, macOS, dan Linux menjalankan versi Node yang persis sama dari image yang sama.

Kendali Tengah dengan Compose Watch #

Bentuk ketiga adalah recap singkat dari Chapter Compose Watch: Compose memantau berkas di host dan bereaksi sesuai aturan yang kita tulis pada blok develop.watch — menyalin berkas yang berubah, membangun ulang image, atau me-restart container:

    develop:
      watch:
        - path: ./src
          action: sync
          target: /app/src
        - path: ./package.json
          action: rebuild

Mari kita telaah dua aturan tersebut: aksi sync menyalin hanya berkas yang berubah ke container tanpa membangun ulang image, dan aksi rebuild mengurus perubahan manifest dependensi yang memang mustahil diselesaikan dengan menyalin berkas. Bentuk ini paling terkontrol — image tetap menjadi sumber kebenaran, host tidak perlu memasang apa pun, dan tiap kelas berkas punya jalur reaksinya sendiri.

Menentukan Pendekatan yang Tepat #

Baris ketiga pada tabel di atas adalah cerita Siti: kinerja bind mount di Docker Desktop untuk Windows dan macOS punya karakter tersendiri yang akan kita bedah pada chapter berikutnya, dan aksi sync yang menyalin hanya berkas yang berubah sering menjadi penawarnya. Baris keempat menegaskan bahwa pilihan tidak saling meniadakan — kombinasi bind mount untuk source code plus aturan rebuild untuk package.json dan Dockerfile adalah pola yang kita rakit bertahap di section ini.

Runbook di README dan .env.example #

Apa pun pendekatan yang dipilih, satu perangkat wajib menyertainya: README sebagai runbook onboarding. Runbook yang baik tidak menceritakan arsitektur lebih dulu, melainkan menjawab satu pertanyaan — “perintah apa yang membuat saya produktif hari ini?” — dalam urutan yang bisa disalin mentah-mentah:

git clone https://git.example.com/budi/katalog-web.git
cd katalog-web
cp .env.example .env
docker compose up -d

Nilai yang bervariasi antar mesin — port yang bentrok, kata sandi lokal — hidup di .env yang dihasilkan dari templat .env.example, sedangkan Compose membaca berkas itu lewat interpolasi yang kita kenal dari Chapter Variable Interpolation. Templatnya di-commit supaya runbook selalu berpasangan dengan contoh nilainya:

POSTGRES_PASSWORD=rahasia123

Pengelolaan yang lebih rapi — profil per kebiasaan kerja, override pribadi yang tidak di-commit, sampai kebersihan resource saat ruang disk menipis — adalah pembahasan utuh Chapter Mengelola Environment Development di ujung section ini. Untuk sekarang, satu templat plus satu runbook sudah cukup untuk menjawab hari pertama rekan baru: satu menit membaca, satu perintah menjalankan.

Kita kini memegang peta pendekatannya, dan sepanjang sisa section ini kita menempuh jalur yang paling menyeluruh: seluruhnya di dalam container. Langkah pertamanya adalah menjadikan kode di host dan toolchain di container bertemu di satu path — pekerjaan bind mount source code, yang membuka trik node_modules yang menjadi fondasi seluruh workflow berikutnya, pada Chapter Bind Mount Source Code.

Referensi #

• Docker Compose — pusat dokumentasi perintah harian untuk menjalankan dan memelihara stack development.
• Use file watch mode — aksi sync, rebuild, dan restart pada develop.watch sebagai pendekatan kendali tengah.
• Docker overview — kerangka besar siklus develop-ship-run tempat workflow harian ini berada.