Sebagai developer, ada satu fase dalam pengembangan aplikasi yang sering terasa jauh lebih rumit daripada menulis kodenya sendiri: deployment.

Saat aplikasi masih berjalan di local environment, semuanya terasa sederhana.

Kita menjalankan:

pnpm install
pnpm run start:dev

Kemudian aplikasi berjalan.

API bisa diakses. Database tersambung. Authentication bekerja. Semua terasa baik-baik saja.

Sampai akhirnya kita mengatakan:

"Oke, sekarang kita deploy ke production."

Dan di sinilah ceritanya mulai berbeda.

Tiba-tiba kita harus memikirkan Docker, environment variables, Node.js version, package manager, database, networking, DNS, CI/CD, secrets, logging, dan berbagai konfigurasi lain yang sebelumnya tidak terlalu terlihat.

Bagi saya, ini menarik karena menunjukkan bahwa menjadi software engineer bukan hanya tentang bagaimana membuat aplikasi bekerja.

Kita juga harus membuat aplikasi tersebut dapat berjalan dengan baik di environment yang berbeda dari komputer kita sendiri.

Dan dari sinilah ketertarikan saya terhadap opsctrl dimulai.

Dari "Works on My Machine" ke Production

Saya rasa hampir semua developer pernah mengalami situasi seperti ini.

Aplikasi berjalan sempurna di laptop.

Kemudian ketika dipindahkan ke server:

It works locally.
It doesn't work in production.

Masalahnya bisa sangat sederhana.

Versi Node.js berbeda.

Package manager berbeda.

Environment variable belum tersedia.

Database configuration berbeda.

Atau sebuah dependency membutuhkan native binary yang tidak kompatibel dengan environment production.

Masalah-masalah seperti ini mungkin terlihat kecil secara individual.

Namun ketika semuanya muncul bersamaan, proses deployment bisa menjadi cukup kompleks.

Terutama ketika kita mulai menggunakan framework seperti NestJS yang biasanya berada di dalam ecosystem yang lebih besar.

Kita mungkin memiliki:

• NestJS application

• PostgreSQL

• Redis

• background jobs

• Docker

• GitHub Actions

• environment variables

• domain

• SSL

• database migrations

• monitoring

• dan berbagai infrastructure lainnya.

Aplikasi kita mungkin hanya terdiri dari beberapa module.

Tetapi infrastructure di belakangnya bisa jauh lebih besar.

NestJS Itu Mudah. Deployment-nya Bisa Berbeda Cerita

Saya menyukai NestJS karena framework ini memberikan struktur yang cukup jelas untuk membangun backend application.

Dengan module, controller, service, guard, interceptor, dan berbagai abstraction lainnya, kita bisa membangun aplikasi yang relatif kompleks dengan struktur yang tetap terorganisir.

Tetapi setelah aplikasi selesai dibuat, pertanyaan berikutnya adalah:

"Bagaimana aplikasi ini akan berjalan di production?"

Misalnya kita menggunakan Docker.

Secara sederhana kita mungkin memiliki:

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

RUN npm run build

EXPOSE 3000

CMD ["node", "dist/main.js"]

Kelihatannya sederhana.

Tetapi production environment jarang sesederhana Dockerfile tersebut.

Kita mulai berhadapan dengan pertanyaan seperti:

• Apakah versi Node.js sesuai?

• Apakah dependency dapat di-build di dalam container?

• Apakah environment variable sudah tersedia?

• Bagaimana database migration dijalankan?

• Bagaimana aplikasi melakukan restart?

• Bagaimana domain diarahkan ke application?

• Bagaimana background worker dijalankan?

• Bagaimana deployment dilakukan setiap kali ada perubahan di Git?

Di titik ini, deployment mulai menjadi pekerjaan tersendiri.

Dependency Kecil Bisa Menjadi Masalah Besar

Salah satu hal yang membuat saya semakin tertarik dengan problem deployment adalah bagaimana dependency yang terlihat sederhana dapat menjadi sumber masalah ketika environment berubah.

Contohnya adalah bcrypt.

Di local machine, kita mungkin hanya menjalankan:

pnpm install

dan semuanya berjalan normal.

Tetapi ketika dependency tersebut harus dikompilasi di dalam Docker container, kondisi environment menjadi penting.

Operating system, architecture, Node.js version, package manager, bahkan C library yang digunakan oleh container dapat memengaruhi hasil akhirnya.

Salah satu contoh menarik adalah kombinasi pnpm 11, Docker, dan native dependencies seperti bcrypt.

pnpm 11 memperketat bagaimana build scripts dependency dijalankan. Jika konfigurasi tidak sesuai, proses install dapat berhenti. Tetapi menggunakan shortcut seperti --ignore-scripts juga bukan solusi yang benar untuk dependency yang memang membutuhkan proses compilation.

Masalahnya bahkan bisa berubah dari:

Build failed

menjadi:

Build succeeded
Runtime crashed

Dan menurut saya, yang kedua jauh lebih berbahaya.

Karena application terlihat berhasil di-deploy, tetapi kemudian gagal ketika fitur tertentu benar-benar digunakan.

Kasus seperti ini menunjukkan bahwa deployment bukan hanya masalah menjalankan docker build.

Kita harus memahami apa yang sebenarnya terjadi di balik proses tersebut.

Di Sini Opsctrl Menjadi Menarik

Yang membuat saya tertarik dengan opsctrl bukan hanya ide bahwa deployment bisa dibuat lebih mudah.

Yang lebih menarik bagi saya adalah bagaimana kompleksitas infrastructure tersebut dapat diabstraksikan tanpa membuat developer sepenuhnya kehilangan konteks teknis.

Menurut saya, abstraction yang baik bukan berarti:

"Developer tidak perlu tahu apa yang terjadi."

Tetapi:

"Developer tidak harus mengulang pekerjaan infrastructure yang sama setiap kali melakukan deployment."

Ini perbedaan yang cukup penting.

Sebagai developer, kita tetap perlu memahami Docker.

Kita tetap perlu memahami database.

Kita tetap perlu memahami environment variables.

Kita tetap perlu memahami bagaimana application berjalan di production.

Tetapi kita tidak selalu ingin menghabiskan sebagian besar waktu kita hanya untuk menghubungkan semua bagian tersebut secara manual.

Developer Seharusnya Lebih Banyak Fokus pada Application

Bayangkan workflow sederhana.

Kita sedang membangun REST API menggunakan NestJS.

Kita memiliki:

NestJS API
    │
    ├── PostgreSQL
    │
    ├── Redis
    │
    └── Background Jobs

Secara application layer, kita ingin fokus pada hal-hal seperti:

@Controller('users')
export class UsersController {
  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

Kita ingin memikirkan:

• bagaimana API bekerja,

• bagaimana data diproses,

• bagaimana authentication diterapkan,

• bagaimana business logic dibuat,

• dan bagaimana product memberikan value kepada user.

Bukan menghabiskan waktu berjam-jam mengulang konfigurasi deployment yang sama.

Di sinilah menurut saya platform seperti opsctrl memiliki nilai.

Bukan karena infrastructure menjadi tidak penting.

Justru sebaliknya.

Infrastructure menjadi semakin penting sehingga kita membutuhkan tooling yang membantu developer mengelolanya dengan lebih konsisten.

Abstraction Bukan Berarti Menyembunyikan Infrastructure

Ada satu hal yang menurut saya penting untuk dibicarakan.

Ketika kita menggunakan platform deployment, ada risiko developer menjadi terlalu bergantung pada abstraction.

Misalnya:

"Saya tinggal klik deploy."

Kemudian ketika sesuatu gagal, kita tidak tahu harus melakukan apa.

Menurut saya, itu bukan tujuan abstraction yang baik.

Platform yang baik seharusnya membuat developer lebih produktif tanpa membuat mereka kehilangan pemahaman teknis.

Saya masih ingin tahu:

Application
    ↓
Container
    ↓
Runtime
    ↓
Database
    ↓
Infrastructure

Tetapi saya tidak ingin setiap project baru memaksa saya mengulang seluruh konfigurasi dari awal.

Bagi saya, itulah salah satu hal yang menarik dari pendekatan opsctrl.

Kenapa Ini Relevan untuk Developer Indonesia?

Saya juga tertarik melihat problem ini dari perspektif developer Indonesia.

Banyak developer memulai perjalanan mereka dengan frontend.

Kemudian belajar backend.

Kemudian mulai membuat API.

Kemudian menggunakan database.

Dan pada akhirnya mereka sampai pada satu pertanyaan:

"Sekarang aplikasi saya mau di-deploy di mana?"

Pada tahap tersebut, deployment bisa terasa seperti dunia baru.

Tiba-tiba muncul istilah seperti:

Docker
CI/CD
Reverse Proxy
DNS
SSL
Container
Registry
Environment Variables
Database Migration
Worker
Queue

Bukan berarti developer tidak mampu mempelajarinya.

Tetapi learning curve-nya cukup besar.

Saya sendiri melihat ini sebagai salah satu area yang menarik dalam developer experience.

Semakin mudah seorang developer berpindah dari:

Idea
  ↓
Code
  ↓
Application
  ↓
Production

semakin cepat mereka bisa memvalidasi ide dan membangun sesuatu yang benar-benar digunakan.

Deployment Seharusnya Membantu Developer Bergerak Lebih Cepat

Pada akhirnya, tujuan deployment bukanlah deployment itu sendiri.

Tujuannya adalah membuat software bisa digunakan oleh orang lain.

Ini mungkin terdengar sederhana, tetapi menurut saya ini merupakan prinsip yang cukup penting.

Kita tidak membangun Docker image karena kita menyukai Docker.

Kita tidak mengkonfigurasi CI/CD hanya karena pipeline terlihat keren.

Kita melakukan semua itu karena kita ingin application kita dapat dikirim ke user dengan cara yang reliable, repeatable, dan predictable.

Dan semakin banyak infrastructure yang kita gunakan, semakin penting automation dan abstraction tersebut.

Yang Saya Pelajari dari Opsctrl

Semakin saya mengenal opsctrl, semakin saya melihat deployment sebagai bagian dari developer experience, bukan hanya infrastructure.

Hal yang sebelumnya saya lihat sebagai pekerjaan terpisah:

Code
Docker
Database
DNS
CI/CD
Deployment

sebenarnya merupakan bagian dari satu perjalanan:

Developer
    ↓
Application
    ↓
Production
    ↓
User

Tools seperti opsctrl menarik bagi saya karena mencoba mengurangi friction di antara tahapan-tahapan tersebut.

Dan saya rasa ini menjadi semakin relevan ketika application yang kita bangun mulai berkembang.

Saat project masih kecil, kita mungkin bisa melakukan semuanya secara manual.

Tetapi ketika jumlah service, environment, deployment, dan developer bertambah, pendekatan manual mulai menjadi expensive.

Bukan hanya dalam bentuk uang.

Tetapi juga dalam bentuk:

• waktu,

• complexity,

• human error,

• dan cognitive load.

Saya masih dalam proses mengenal lebih jauh bagaimana opsctrl bekerja dan bagaimana saya bisa berkontribusi di dalamnya.

Tetapi satu hal yang sudah cukup menarik perhatian saya adalah problem yang ingin diselesaikannya.

Sebagai developer, kita ingin membangun software.

Kita ingin menulis code.

Kita ingin membuat product.

Dan pada akhirnya, kita ingin user dapat menggunakan apa yang kita bangun.

Infrastructure tetap penting.

Deployment tetap penting.

Tetapi proses menuju production tidak seharusnya selalu menjadi sumber friction yang sama berulang kali.

Bagi saya, inilah alasan mengapa pendekatan seperti opsctrl menarik.

Bukan untuk menghilangkan infrastructure dari dunia developer.

Tetapi untuk membuat infrastructure lebih mudah dikelola, lebih repeatable, dan lebih dekat dengan workflow developer.

Dan mungkin, bagi developer yang sedang berada di perjalanan yang sama seperti saya — dari sekadar membuat application sampai benar-benar menjalankannya di production — deployment bukanlah sesuatu yang harus ditakuti.

Deployment adalah bagian dari software engineering.

Dan semakin baik tools yang kita gunakan, semakin banyak energi yang bisa kita kembalikan kepada hal yang paling penting:

building software.