DEV Community: ASTOMO PANCORO PUTRO

ABCDE nya DevOps itu Begini...

ASTOMO PANCORO PUTRO — Thu, 30 Apr 2026 02:28:24 +0000

Dalam dunia pengembangan perangkat lunak, budaya DevOps semakin menjadi hal yang tak dapat dikesampingkan. Namun banyak organisasi yang hanya bermodalkan semangat mencoba menerapkan budaya DevOps sebab pengetahuannya minim dan justru fokus pada automation. Padahal, inti dari budaya DevOps itu hanyalah sederhana saja.

A: Agile - Lincah

Lincah itu dimaknai sebagai kemampuan organisasi untuk merespon perubahan dengan cepat. Namun bukan berarti perubahan business flow di luar kontrak yang disepakati. Lalu apa dong? Perubahan yang direspon dengan cepat adalah perubahan yang memiliki business value tinggi bagi klien. Business value ini artinya, perubahan fitur tersebut bisa menggenjot revenue bagi klien. Di sini, lincah bermakna memberikan challenge kepada klien: mengutamakan fitur yang mendesak, penting, dan business value tinggi supaya timeline project tetap sesuai kontrak yang disepakati - dengan kata lain klien harus memprioritisasi ulang fitur yang sudah disepakati.

B: Blameless - Tidak mencari kesalahan

Dalam organisasi, permasalahan teknis bisa timbul kapan saja. Dengan budaya DevOps masalah itu dihadapi bersama sebagai tim, bukan menunjuk siapa yang salah. Seringkali dalam organisasi masih tertinggal budaya feodal masalah senioritas. Bukan dalam hal pengalaman, namun masa kerja. "Gue lebih lama di sini masa nurut-nurut aja sama orang baru". Sehingga ide-ide segar seringkali diabaikan. Padahal dalam ide tersebut ada paparan permasalahan yang bisa jadi kendala di kemudian hari. Dalam budaya feodal, tentu harus cari kambing hitam alih-alih melihat akar permasalahan (root cause analysis) dan memikirkan bersama solusinya. Dengan budaya DevOps, permasalahan dipandang sebagai tantangan bersama untuk dicarikan solusinya dan menjadi pembelajaran di masa yang akan datang.

C: Collaboration - Kerjasama

Kerjasama dalam budaya DevOps itu makna nya luas. Tidak sekedar mengerjakan suatu hal bersama-sama, namun juga lintas platform. Dalam satu project tidak mungkin satu orang dev mengerjakan semuanya sendirian, apalagi jika menghadapi suatu tool atau runtime yang tidak dia kuasai. Hal semacam ini bukan sesuatu yang memalukan. Dengan budaya DevOps, kerjasama dengan personal yang memiliki kecakapan dalam bidang lain justru wajib. Misalnya ada project web app berbasis Node.js, namun memerlukan suatu tool berbasis python atau golang. Meng-hire personal yang bisa mengerjakan tool tersebut lebih menguntungkan ketimbang mencoba sendiri oleh personal yang tidak punya skill di situ. Justru jika memaksa mencoba sendiri tanpa skill malah akan menghabiskan waktu.

D: Decentralised - Berbagi

Salah satu manfaat menerapkan budaya DevOps adalah memecah kebuntuan antara developer dan operation. Namun budaya DevOps juga menekankan pentingnya berbagi. Pekerjaan tidak harus dikerjakan sendiri, namun dipecah-pecah menjadi module yang bisa dikerjakan banyak orang. Kebutuhan teknologi (tech stack) juga wajib dibagikan informasi nya ke seluruh tim supaya ditemukan solusi final dan permanen. Seperti soal deployment apakah memakai containerisasi atau hanya transfer file lalu mensetup runtime di server sasaran. Kemudian perlu nya ada stage dan production server. Dan sebagainya. Semua hal tersebut perlu dipikirkan bersama antara developer dan operation. Tidak ada yang namanya terima jadi dalam budaya DevOps.

E: Empathy - Perduli

Perduli bermakna menyediakan solusi untuk menghadapi kendala bersama. Perduli ini lebih kearah investasi ketimbang ide. Investasi bukan berarti harus menyediakan device gahar, namun menciptakan sistem dan kondisi yang bersifat inklusif. Misalnya, tidak mewajibkan tim untuk menggunakan laptop dengan spesifikasi atau OS tertentu (BYOD/Bring Your Own Device). Solusinya bisa dengan menyewa layangan hosting murah untuk membikin sistem self hosted yang terintegrasi untuk proses development, testing, dan deployment. Perduli dalam bentuk lain bisa juga dengan tidak menambah overtime dengan alasan extra effort karena habis cuti. Cuti (leave) adalah hak setiap personal tim. Pekerjaan yang dipending sementara seharusnya diprioritisasi ulang sehingga bagian yang belum dikerjakan adalah bagian yang tidak mengganggu keseluruhan business flow. Misalnya pekerjaan menambah layer 2FA pada login, jika ada permintaan verifikasi via email dan via whatsapp maka setelah salah satu dikerjakan maka metode verifikasi lain bisa dipending dan dikerjakan di hari-hari selanjutnya. Sebab multi metode untuk verifikasi itu bersifat redundant dan tidak mendesak jika salah satu saja sudah bisa digunakan. Namun tidak berarti redundancy ini diabaikan.

Kesimpulan

Budaya DevOps memecahkan kebuntuan antara development dan operation. Inti dari budaya DevOps adalah kerjasama dan perduli, sehingga setiap permasalah yang dihadapi dipandang sebagai tantangan bersama yang perlu dicarikan solusinya. Solusi dalam budaya DevOps selalu bersifat inklusif dan memberikan keuntungan bersama.

Waktu nya Males Belajar Tech Stack (Baru)

ASTOMO PANCORO PUTRO — Sat, 06 Sep 2025 08:34:42 +0000

Perkembangan model pembuatan aplikasi semakin meriah akhir-akhir ini. Hanya dalam hitungan bulan, beragam tech stack baru bermunculan -- dengan akronim nya masing-masing. Tech stack menggabungkan berbagai lini dalam pembuatan aplikasi -- mulai dari bahasa pemrograman, sistem deployment, sampai manajemen data. Di tengah membanjirnya tech stack baru timbul skeptisme: perlukah para dev yang sudah berkecimpung di suatu tech stack untuk segera beradaptasi dengan tech stack baru? Benarkah alasan bahwa bertahan pada suatu tech stack akan tertinggal kemajuan? Baca sampai selesai beberapa fakta menarik berikut ini!

Fun Fact #1: Client tidak perduli dengan tech stack yang digunakan pada aplikasi yang dibutuhkannya

Fakta menarik ini cukup mencengangkan bukan? Pada dasarnya client mengabaikan detil teknis aplikasi yang dibutuhkannya. Mereka menurut saja, namun memiliki emphasis (penekanan). Untuk client di bidang keuangan, emphasis pada keamanan dan kecepatan. Untuk client di bidang commerce, emphasis pada kemampuan handling request massal secara real time. Client bidang lain emphasis pada total cost of ownership yang terjangkau. Sebuah quote menarik untuk disimak:

there is no technology fits all client needs

Tim development yang baik harus memerhatikan emphasis ini. Pemilihan tech stack tinggal menyesuaikan emphasis dan tentu saja ketersediaan budget. Jangan sampai terjadi over budget malah mendapatkan tech stack yang tidak memenuhi target emphasis. Atau sebaliknya, budget mepet dipaksa memakai tech stack terkini dengan fitur yang sebenarnya di luar emphasis client.

Fun Fact #2: Jumlah penduduk bumi sekitar 8 milyar dan semua nya butuh makan

Mungkin fakta menarik ini menimbulkan pertanyaan: "apakah saya harus ikut memikirkan kebutuhan makan semua penduduk bumi?". Dalam kaitan dengan perkembangan tech stack, jika kita perhatikan alasan terkuat seseorang berusaha menguasai segala macam tech stack adalah takut tidak kebagian job yang menggunakan tech stack yang belum dikuasainya. Pada dasarnya alasan ini bisa dibilang mengada-ada. Betul, ada sebagian software house yang menentukan tech stack terlalu dini, bahkan sebelum mengetahui real kebutuhan client dan merekrut dev baru. Namun hal tersebut tetap saja tidak dapat dijadikan landasan agar setiap dev mengantisipasi segala kemungkinan.

Seandainya dalam kondisi tertentu tim dev terpaksa memakai lebih dari 1 macam tech stack, maka sikap bijaksana yang dapat diambil adalah dengan collab -- memecah project sesuai dengan tech stack yang dikuasai anggota tim dev.

Dalam setiap keputusan tim dev selalu ada trade off (harga):

jika memaksa dev untuk bekerja dengan tech stack yang tidak dikuasai maka akan memperlambat proses development karena dev lebih banyak beradaptasi ketimbang mengembangkan fitur yang dibutuhkan client
jika merekrut dev serba bisa maka akan menurunkan performa dev ybs sebab fokus nya bercabang cabang
jika melakukan collab untuk menyesuaikan skill dev terhadap tech stack yang digunakan maka akan menambah biaya pembuatan aplikasi
jika melibatkan AI maka selain ada penambahan biaya untuk sewa AI -- yang hanya berguna saat development -- maka timeline akan makin panjang khususnya untuk melakukan code check yang dihasilkan AI guna memastikan kesesuaian dengan fitur yang dibutuhkan client

Dari trade off tersebut, yang paling bijaksana dan realistis tetaplah melakukan collab. Tentu saja, poin terpenting dari collab adalah memberikan kesempatan bagi dev baru untuk meraih pendapatan yang diharapkan dapat membantu mengurangi pengangguran.

Fun Fact #3: Project yang dikerjakan oleh banyak dev cenderung lebih stabil

Fakta menarik ini tak kalah mencengangkan bukan? Mungkin banyak yang merasa heran -- khusus nya para dev serba bisa dan single fighter -- kok bisa?

Tentu saja! Sebab project yang dikerjakan oleh banyak dev itu memiliki bagian-bagian yang terpisah. Jika satu bagian mengalami crash, bagian lain tetap normal. Dengan begitu test juga bisa dilakukan bertahap, bagian per bagian. Tak hanya itu, deployment pun bisa dilakukan bertahap pula, bagian per bagian. Selain itu semakin banyak dev yang terlibat, semakin banyak pula kepala yang ikut memikirkan solusi atas permasalahan, bug fixing, serta patch. Dengan sendirinya, project tersebut semakin stabil per rilis. Quite simple!

Berkaca dari project-project open source besar, terlihat bahwa project tersebut memiliki sekian ratus contributor yang bekerja di bagian yang berbeda-beda. Hal ini terlihat dari antrian pull request di repo project tsb. Dan hasilnya bisa kita lihat, project tersebut bisa rilis stable version secara rutin.

Namun dibalik luar biasanya para contributor, ada skeptisme: apa yang terjadi jika ada dev yang tiba-tiba meninggalkan bagian nya yang belum selesai? bukankah akan menimbulkan banyak legacy code? Nah, di sini lah clean code mengambil peran. Project open source maupun open contribute wajib menerapkan clean code termasuk coding style standar. Hal ini akan memudahkan handover task antar dev tanpa perlu transfer of knowledge lagi.

Fun Fact #4: Tech stack hopping bisa merugikan diri sendiri dan tim

Inilah fakta menarik yang paling mencengangkan! Tech stack hopping makna nya adalah berpindah-pindah tech stack sebelum benar-benar menguasainya. Alasannya sederhana saja: harus sesegera mungkin beradaptasi dengan tech stack baru supaya memiliki kesempatan untuk mendapat job.

Jika kita melihat ke linkedin atau github, mungkin sering ada yang mengisikan informasi tech stack yang sudah dikuasai. Ada yang mengaku bisa lebih dari 3 bahasa pemrograman, ada yang mengaku bisa lebih dari 3 framework, ada yang mengaku bisa lebih dari 3 deployment system, dst. Namun ketika interview banyak yang failed sebab fitur-fitur dari tech stack yang disyaratkan dalam suatu project ternyata alpa dikuasai pelamar. Parahnya, ada tim rekrutmen yang tetap menerima pelamar meski minim penguasaan nya terhadap tech stack yang disyaratkan.

Kenapa terjadi ada pelamar yang portfolio nya wow namun aslinya penguasaan nya minim? Ya itu tadi, tech stack hopping. Akibatnya mereka cenderung hanya melatih skillnya pada fitur-fitur standar. Katakan ada backend framework baru maka para tech stack hopper hanya melatih pada CRUD namun meninggalkan coding standard, fitur-fitur penting bahasa basis nya, middleware, dst. Dalih nya fitur tadi bisa dipelajari sambil jalan.

Kerugian tim yang diisi tech stack hopper jelas: project berjalan tersendat-sendat sebab ada fitur-fitur dasar yang dibutuhkan namun tidak dikuasai secara mendalam oleh dev nya, misalnya integrasi oAuth dengan backend framework atau integrasi payment gateway dengan frontend framework. Sedangkan kerugian di sisi tech stack hopper, jam produktif nya tersita untuk mendalami tech stack yang digunakan.

Atas dasar inilah penting bagi seorang dev untuk tidak buru-buru memelajari tech stack baru sebelum benar-benar menguasai tech stack lama. Meskipun ujung-ujung nya terlihat stuck pada 1 atau 2 tech stack namun dia bisa bekerja lebih optimal berkat penguasaan nya yang mendalam.

Kesimpulan

Hal yang bisa kita tarik dari beberapa fun fact di atas ada pada quote yang bermakna tidak ada teknologi bisa memenuhi segala kebutuhan client. Suka tidak suka akan ada saat nya tim dev memakai lebih dari 1 macam teknologi. Dan mau tidak mau harus melakukan collab dengan banyak dev yang skill nya beragam. Dev yang baik bukan yang mengantisipasi perkembangan teknologi namun yang siap bekerjasama untuk membuat aplikasi yang bekerja sebagaimana seharusnya.

Hilirisasi Fiber di PHP dapat Membuka 19 juta Lapangan Lambo

ASTOMO PANCORO PUTRO — Thu, 14 Aug 2025 09:58:08 +0000

Bahasa pemrograman PHP terkenal melakukan proses yang bersifat blocking, yakni sumber daya tidak dapat dipakai untuk keperluan lain sampai proses selesai. Namun di versi 8.* ada peningkatan fitur yang memungkinkan developer untuk menghentikan proses dan menjalankannya kembali kapan saja.

Mengenal Fiber

Fiber merupakan suatu class di PHP yang berguna untuk menjalankan proses yang dapat dihentikan (suspend) dan dijalankan kembali (resume) kapan saja sesuai kebutuhan. Konsep Fiber ini mirip dengan async di Javascript namun dengan perbedaan, proses di dalam Fiber secara default hanya bisa resume satu kali saja. Berikut ini cara mendefinisikan Fiber.

<?php

$timer = new Fiber(function($argument){
    $value = Fiber::suspend("your message");
    echo $value;
});

Di dalam instance Fiber ada sebuah callback yang dapat menerima argumen. Di dalam callback, ada pemanggilan method static suspend() yang akan langsung menghentikan proses dan mengembalikan pesan di argumen method ini.

Mengontrol Fiber

Untuk memulai Fiber caranya sbb.

<?php

$response = $timer->start("message");
echo $response;

Method start() akan memulai Fiber dalam kondisi berhenti (suspended), memasukkan nilai argumen nya sebagai argumen callback Fiber, dan menangkap nilai dari argumen method suspend(). Untuk menjalankan kembali Fiber cara nya sbb.

<?php

while(!$timer->isTerminated()){
    $timer->resume("message");
}

Di sini digunakan infinity loop while yang akan berhenti saat kondisi Fiber mati (terminated) sambil memanggil method resume(). Argumen method ini akan dikembalikan oleh method suspend() dan bisa ditampilkan setiap iterasi selama Fiber belum mati. Secara umum proses Fiber dapat dilihat pada flow chart berikut.

Gbr 1. Diagram alir proses Fiber di PHP

Contoh Koding Fiber dan Penjelasan nya

Gbr 2. Contoh koding Fiber

Pada gambar di atas bisa kita pecah menjadi 3 bagian. Bagian pertama ada definisi Fiber. Pada definisi ini terdapat sebuah loop for yang panjang nya dibatasi oleh argument callback. Di dalam loop for terdapat function sleep() yang berguna untuk menunda eksekusi Fiber selama 30 detik. Selanjutnya perintah Fiber::suspend() akan otomatis menghentikan Fiber saat dijalankan pertama kali. Secara default, method suspend() ini akan menampilkan pesan dari argumen nya saat dijalankan pertama kali lalu akan terminate. Namun looping for bisa digunakan untuk menunda terminate selama belum mencapai akhir loop.

Bagian kedua merupakan perintah untuk menjalankan Fiber pertama kali. Dalam hal ini digunakan method start(). Argumen method ini akan diterima oleh callback, sementara method ini akan menerima pesan dari Fiber::suspend(). Setelah pesan diterima, defaultnya Fiber akan terminate.

Bagian ketiga merupakan suatu infinity loop while. Selama Fiber tidak mengirim sinyal terminate, maka status Fiber::isTerminated akan false sehingga loop terus berjalan. Di dalam loop terdapat perintah resume(). Argumen dari perintah ini akan diterima oleh Fiber setelah suspend(). Karena itulah argumen resume() hanya berisi current timestamp. Berikut ini adalah hasil akhir dari proses Fiber di PHP.

Gbr 3. Hasil akhir proses Fiber di PHP yang dijalankan lewat terminal

Pakai Atribut di PHP Nggak Perlu Bayar Royalti

ASTOMO PANCORO PUTRO — Tue, 12 Aug 2025 05:01:30 +0000

Perkembangan bahasa pemrograman PHP sedemikian pesat nya. Di rilis terbaru nya versi 8.*, bahasa ini menawarkan syntax baru yang dapat digunakan untuk memproses class pada saat runtime.

Mengenal Attribute

Attribute adalah sebuah keterangan (annotation) yang dapat diproses oleh PHP dan dapat memengaruhi class dan komponennya. Untuk menuliskan attribute syntax nya sbb:

#[NamaAttribute]

Berikut ini beberapa contoh penempatan annotation pada suatu class

<?php

#[ClassAttribute]
class MyClass {

#[PropertyAttribute]
private $my_property;

#[MethodAttribute]
public function myMethod()
{ 
}

private function myJob(#[ParamAttribute] $request)
{
}

}

Penamaan pada attribute ini mengikuti aturan fully qualified name di PHP, yakni memerlukan namespace. Dengan sendirinya wujud attribute adalah sebuah class.

Mendeklarasikan Attribute

Untuk mendeklarasikan attribute, sama saja seperti mendeklarasikan class di PHP. Namun perlu ditambahkan annotation #[Attribute]. Berikut ini contoh nya.

<?php

namespace MyAttributes;

use Attribute;

#[Attribute]
class MethodAttribute {
public function __construct($value)
{
}
}

Sedangkan untuk menambahkan attribute, maka annotation harus ditempatkan di bagian class yang sesuai.

<?php

use MyAttributes\MethodAttribute;

class MyClass {
#[MethodAttribute("hello")]
public function myMethod(){
}
}

Annotation bisa menerima argumen jika saat deklarasi ditambahkan konstruktor. Nantinya nilai dari argumen ini bisa dipanggil saat diproses.

Memproses Attribute

PHP menyediakan built in interface bernama Reflection yang bisa digunakan untuk menedeteksi annotation yang ditambahkan pada class tersebut. Interface ini terdiri dari beberapa class sesuai dengan bagian class yang hendak dimodifikasi. Class yang tersedia antara lain sbb.

ReflectionClass -- untuk memproses class
ReflectionProperty -- untuk memproses property
ReflectionMethod -- untuk memproses method
ReflectionParameter -- untuk memproses parameter

Untuk mendeteksi annotation, tiap-tiap class tersebut memiliki method getAttributes yang mengembalikan array dari semua annotation yang terdeteksi. Sebagai catatan, tiap komponen class bisa memiliki lebih dari satu annotation. Array ini terdiri atas class ReflectionAttribute. Class ini juga memiliki method yang bisa digunakan untuk berinteraksi dengan annotation yang dipilih. Berikut ini contoh memproses annotation.

<?php
use MyAttribute\MethodAttribute;
use MyClass;

function processAttribute(){
  $method = new ReflectionMethod(MyClass::class,"myMethod");
  $attr = $method->getAttributes(MethodAttribute::class);
  foreach($attr as $item){
    //panggil attribute yang terdeteksi di sini
    $attr_class = $item->newInstance();
  }
  //panggil class di sini
  $class = new ReflectionClass(MyClass::class);
  $main_class = $class->newInstance();
}

Contoh Kode Pemanfaatan Reflection dan Annotation

Gbr 1. Deklarasi Attribute

Gbr 2. Annotating Class

Gbr 3. Parsing Attribute (gunakan require jika tidak autoloading class)

Gbr 4. Hasil akhir